SSL works on Safari and Chrome but not Firefox

[nasiralamreeki]

SSL works on Safari and Chrome but not Firefox. It seems to work fine for ipv4 traffic but not ipv6. I have a A record setup for ipv4 and ipv6 shouldn’t both work?

My domain is: wiki.somedomain.com

I ran this command: certbot --nginx --redirect --agree-tos --no-eff-email -d wiki.somedomain.com -m myemail@somedomain.com

It produced this output: great success

My web server is (include version): Nginx

The operating system my web server runs on is (include version): Ubuntu 20.04 LTS

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.16.0

[Osiris]

Your webserver behaves differently on IPv4 versus IPv6: IPv4 works fine: the webserver speaks HTTP on port 80 and HTTPS on port 443. However, through IPv6 there is a problem: while it speaks HTTP on port 80, which is expected, it also speaks HTTP on port 443! And not HTTPS!.

This is probably due to a misconfiguration in your nginx.

[nasiralamreeki]

Right I just noticed this so is there something I need to do differently to configure both for ipv4 and ipv6? I just followed the directions for Certbot

[Osiris]

It probably means your nginx configuration before you ran certbot had a certain configuration which wasn't "compatible" with certbot I guess. But without looking at the configuration, it's hard to tell.

Could you provide us the output of the command sudo nginx -T? Please put three backticks (```) on a separate line above and below the configuration output.

[nasiralamreeki]

Redacted Redacted Redacted

[Osiris]

@nasiralamreeki

server {
        listen 443 ssl ;
        listen [::]:443 ;
    server_name wiki.hanbaliyyah.com; # managed by Certbot

Here you see the problem: a missing ssl at the second listen. I'm not sure why certbot wouldn't have added it when it made that server {} block though.

When I tried to reproduce your problem, I noticed that certbot also adds # managed by Certbot to the listen directives when it copies those directives from the HTTP server block to the new HTTPS server block. But those comments are missing from your listen directives. Did you manually add or modify those?

[nasiralamreeki]

I have not made any modifications this Nginx base was generated by Vultr’s Mediawiki one click install I just followed their directions to use Certbot.

They don’t even want to provide any support for their in house one click install.

[Osiris]

Could be that Vultrs software/scripts does something funny to the nginx configuration.

In any case, you should substitute listen [::]:443 ; with listen [::]:443 ssl ; and reload nginx afterwards.

[nasiralamreeki]

Thanks this worked perfectly just did what you suggested and ran Certbot again and it worked

[Osiris]

Just reloading nginx would have been fine. Now you've issued a lot of unnecessary certificates, adding more and more load on the Let's Encrypt infrastructure:

https://crt.sh/?q=wiki.hanbaliyyah.com&deduplicate=y

You could have just used the first one, as this was not a certificate issue, but a nginx configuration issue.

[nasiralamreeki]

I didn’t renew just had Certbot reinstall the same certificate. When I reloaded Nginx it didn’t work until I had Certbot reinstall the cert.

[Osiris]

That's very odd for multiple reasons.

In any case, 4 identical certificates have been created today, perhaps during a different step in the process.

[ebenner]

Hello,

As a note we are rectifying this issue now. There was a bit of an issue with the certbot repo after we moved to 20.04 but we have started pushing out the snaps. As for the nginx misconfiguration, there was a bit of an oversight as we prepared for more wide spread v6 rollout. This issue will be dealt with promptly and more suitable images released.

Thank you for pointing this out for us!

[nasiralamreeki]

Yeah those reissues were before I posted here while I was still trying to figure out why Certbot wasn’t working. It seems Vultr is aware of the Certbot and Nginx issues in their One-Click App and anticipating to update that today with fixes and possibly update Mediawiki to 1.36.1 too.