I am running six domains on a CentOS7 webserver using Apache 2.4
I have now installed LetsEncrypt, installation went flawessly.
All my domains are working securely, smooth as silk, on every browser EXCEPT Firefox.
Firefox (latest:47.0.1) responds with “Your connection is not secure”
“The owner of (your domain) has configured their website improperly”
".Error code: SSL_ERROR_BAD_CERT_DOMAIN"
Well, I beg Mozilla’s royal, arrogant pardon! My sites are NOT configged improperly!
All my domains pass SSLTest “A” Green:
No issues whatsoever.
My cert and private key match.
I have added the keys and chain to my ssl.conf file.
Everything works great - EXCEPT it does not work on Firefox.
Must I actually submit to my customers thinking my sites are not secure?
I have spent HOURS on this forum and others to find no solution to this problem.
I see other people have this problem, too. Also getting no solution.
Am I missing something?
What’s up? Why is this happening? Does someone pahleeze know how to fix it?
Thank You!
Some information about your setup would be helpful in figuring out what’s going on. To give a few things off the top of my head, the actual domain name(s) you’re using, what OS your server’s using, and what web server. Do you get the same error with all your domains, or only on some of them? I can say from experience that Firefox accepts Let’s Encrypt certs on Mac, Windows, and Linux, so there isn’t an inherent compatibility
Uh, hello, dan.
Thank you for your response, although a puzzling one.
All of your questions about my “setup” are already clearly stated in the post.
-CentOS7
-Apache 2.4
-Firefox (latest:47.0.1)
All my domains get a perfect “A” score with no issues whatsoever on SSLTest.
So, LetsEncrypt is obviously not always consistent.
Hopefully, we’ll hear from someone who has experienced and solved the issue.
The point of asking about your domain, rather than generalities, is that of course many people here (including me) have used Let’s Encrypt certificates and their sites work just fine with Firefox. Thus it’s not some general problem “Let’s Encrypt doesn’t work with Firefox” but something more specific. So, there are two kinds of problem you might be having and @danb35, @serverco and so on are trying to help figure out which
It could be that your Firefox is incorrectly configured somehow, particularly if this only happens for one particular Firefox install on one machine you have. Examples off the top of my head: You might have disabled the IdenTrust CA public key from the Mozilla NSS trust store, you might have configured Firefox to connect to some proxy instead of your real site, or you even might have some malware installed which is redirecting connections
It could be that, despite the SSLTest (SSL Labs?) score you have incorrectly configured your web servers somehow and this makes Firefox allergic for some reason. If others can view your site they may either find clues to what’s wrong with it, or be able to reassure you that, for everybody else at least, it works with Firefox.
I’ve seen DNS caching cause similar issues in the past. If you recently changed the IP address of your domain, Firefox might still have the previous IP address cached (I think it behaves a bit differently with regards to DNS TTL, compared to other browsers). When you try to connect to that IP via HTTPS and it’s not configured to serve HTTPS for that domain (but it is for others), you might see something like this.
You might also want to check the certificate that Firefox sees for that domain. Clicking on the lock icon and then “More information” brings you to a dialog with a “View Certificate” button. This will allow you to inspect the certificate and check things like the Common Name, Subject Alt Names (all domains this certificate is valid for), etc. Maybe there’s a clue in there somewhere.
Would you happen to have a hyphen as the first or last character in your subdomain (Or main domain name)? There is a Firefox bug that causes that bogus error to show up in that case.
I apologize--you're right that much of the information was already there. But not all of it; perhaps you need to read more closely as well. It is most definitely not the case that Firefox has a problem with LE certs; I and many others are using it without a problem. It is therefore almost certainly a configuration problem of some sort. So, back to the my questions that you didn't answer in your original post, or since:
What are the actual domain names you're using?
Does this problem happen on all them, some of them, or just one?
Thanks very much to everyone for your replies.
I am very grateful for the feedback.
I’ve been reluctant to announce any of my domain names only because I’m not anxious to have people
going to my sites when they are not working properly. I hate to have people have go through the business of
adding an exception, rather than making the thing work properly first.
Someone commented about changing my IP address. Yes, I did recently. I’m migrating my sites to a new server,
so I’ve had to change IP, as well as DNS servers, dns records, and everything. Another erason I’m reluctant to
publish the domain names wirh everything ‘half-baked’.
You may take a look at this one: “guestplaces.net”
***(But please understand, it’s all in disarray during this
migration and LetsEncrypt business. Nowhere near ready-for-prime-time.)
I discovered the Firefox works properly when I do not use the “www” with the domain name. With the FQDN
using the “www”, it produces the error.
I am reminded that the instructions for installing LetsEncrypt that I used specfified that I enter only
domain names in the request, not to use the www prefix on them.=. Like this:
"-d domian1.com -d domain2.com -d domain3.com" etc…
I then made a in /etc/httpd/sites-available/ for each domain.
Each tag include’s a ‘ServerAlias’ entry for 'www.domain.com’
The ServerAlias tag is also, as always, in ny httpd.vhost.conf for every domain name.
Why don’t the ServerAlias tags work only on Firefox?
Maybe those LE installation instructions were incorrect. Must I start over and include a "-d www.domain.com"
item AND a “-d domian.com” for every domain name? I hate to start all over again if that’s
not the problem. Must I also include “instance.domain name” entries for every relevant instance?
If so, I could certainly have been thrown off-track by the fact that all browsers work except Firefox.
Is Firefox now the ‘industry standard’ in the matter?
I added these to my ssl.conf file:
SSLProtocol all -SSLv2 -SSLv3
SSLCertificateKeyFile /etc/letsencrypt/live/mydomain.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/mydomain.com/fullchain.pem
The SSL Protocol to satisfy the SSLTest
and without the Certificate files added, httpd would not start
Yes, the cert needs to include every FQDN the site will be reached by. You don't need to include the instances if those names are never intended to be used directly in a way that requires a valid cert.
If your domain is available at both example.com and www.example.com, both domains will need to be included explicitly, i.e. -d example.com -d www.example.com. There's nothing special about the "www" subdomain in terms of SSL, it's just another domain and if it's not included on the certificate, that certificate won't be valid for that domain.
What's interesting is that Chrome automatically redirects to https://guestplaces.net when you browse to https://www.guestplaces.net. I haven't seen this behaviour before and couldn't find any documentation for this, but it seems like this is a convenience feature Chrome might have implemented for sites that only have a certificate for the main domain and not the www subdomain, maybe because this is a common misconfiguration. That's probably the reason why you're only noticing this in Firefox, but from a technical point of view, the implementation in Firefox would be correct here.
This is eye-opening information. These detail points were woefully excluded from the instructions I used.
(and I dont see any reason for the ServerAliases in /etc/httpd/sites-available/
They just take up space if they perform no function.)
Now that I understand this, I’m considering leaving my install as it is.
I might be able to use the anomolies to my advantage in controlling how my sites operates.
Thanks again to all who helped on this one.
The problem is solved and my servers are working great!
Let’s Encrypt is terrific! If anybody comes accross this and needs help on CentOS7,
please feel free to message me for assistance. I look forward to helping others
when I have the opportunity.
-RR
I’*d rather recommend posting any help request public in this forum. That’s why we have a forum. Every thread helps other users who have the same problem, so PM help is not a good thing.
If you want to help just browse around in this forum a bit.
Was just reading this thread somewhat randomly… Big thanks to the community for your help! I love seeing someone come in with a problem and end up a happy Let’s Encrypt user soon after.
Without posting the entirety of the certificate information from Firefox and your DNS records (or providing a domain name for us to dig) it’s difficult to accurately diagnose (easy mistake to make). To repeat what others have posted, I have had no problems with any recent version of Firefox and Lets Encrypt.
Just a guess - but it’s likely that your certificate doesn’t include the www. subdomain, which leaves you two ways to fix the problem: create a new certificate that includes the www. subdomain; or do as I do and use .htaccess to redirect calls to www.example.com to example.com (and http:// to https://).
If, after reading the details of your certificate errors in Firefox you find that the information is incorrect (i.e. Firefox is wrong) try changing your Firefoxprofile (and).
Note that while the SSL Test is a great tool, it’s not perfect. I’d normally recommend that people don’t use it until they’ve ensured that their DNS records are correct. A very common mistake is to overlook the fact that www is a sub-domain… www should be a CNAME, not an ANAME.
If that is the cause of your problem it should show in the SSL test when you enter www.example.com as the domain to test.
Just a suggestion, but you might consider not trying to use a single certificate for so many domains - if for no other reason than to make isolation testing and future hosting flexibility less, um, difficult.