I've configured an NGINX reverse-proxy with SSL certificate and it works fine in Chrome and IE, but give me an SSL error (SEC_ERROR_UNKNOWN_ISSUER) in Firefox.
Why is that?
I've just found another answer to a similar problem that explains that this happens if the certificate chain is not fully sent by the server (or in this case the load balancer).
This other answer explains that Chrome looks for this missing chain certificates by itself while Firefox does not. Actually Firefox caches intermediate certificates from earlier connections to other sites, but in my case since I'm mostly using Chrome, Firefox didn't had any cache of these Sectigo (Comodo) root certificates, that's why I was getting the validation error.
When I purchased my PositiveSSL certificate I've received both the "crt" file for my domain but also a "ca-bundle" file which is the certification authority bundle. Both these files should be concatenated (first my certificate, followed by the certificates for the authority chain), and this combined file is what should be configured as ssl_certificate in NGINX.
Related
I've been using an online SSL checker to check certificate validity for several sites.
One thing I noticed is that many websites have wildcard certificates - especially those hosted on common web hosting sites, such as goDaddy: *.onlinestore.godaddy.com
But those sites have custom domains and so when validating the SSL cert I can see an error where the hostname does not match the altnames listed in the certificate.
But all major browsers (tested chrome, FF, IE and Safari) still show the site as secure. Do the browsers not care that the domain names are not listed in the cert, and isn't that a security vulnerability?
Example: https://www.sslshopper.com/ssl-checker.html#hostname=www.cinnamonmotif.com
In case a wildcard certificate is installed on a domain, the browser only check the certificate validity and wildcard rule. As long as this rule is true the certificate id trusted and no warning appears.
If you look at the certificate that the browser resolved you'll see that it's different than sslshopper.com resolved.
When you go in a modern browser the client sends the TLS Server Name Indication extension, and the site notices that it's supposed to serve up the cinnamonmotif.com certificate.
SslShopper saw *.onlinestore.godaddy.com, which is certificate 0x6068c7475ab4ee2a from Go Daddy Secure Certificate Authority - G2.
With SNI the served up certificate is cinnamonmotif.com, certificate 0x3e0240d9425e8120 from Go Daddy Secure Certificate Authority - G2.
The fact that the browser saw a different certificate, which is a hostname match, is why the browser says it's a legitimate connection.
I have installed an SSL certificate on my Apache server, but when I access the site via URL from a different machine, an HTTPS error is shown and viewing the certificate details says "this certificate has an invalid digital signature"
If I view the same URL from within the server itself, the certificate is fine and there is no HTTPS error.
I'm not sure what to look for in httpd.conf. Any advice?
Thanks!
You could use SSL Labs to find any SSL misconfigurations: https://www.ssllabs.com/ssltest/
There you can also see if your certificate is correct and trusted.
I have installed SSL Certificate manually that I had brought from Godadday. It installed successfully but it shows self signed certificate which is not trusted or displays cross on https.
What is the solution ?
It is showing because it does not recognized the certificate that you get from Godaddy.
The CSR certificate has to upload on your site and make changes on apache config file.
Make sure your CSR file should not match with the private key that you submitted to verify your site.
Installing a SSL certificate requires some server administration knowhow, especially updating web server configuration.
DigitalOcean has a great tutorial on how to install a SSL certificate from GoDaddy: https://www.digitalocean.com/community/tutorials/how-to-install-an-ssl-certificate-from-a-commercial-certificate-authority#example-ca-2-godaddy
Maybe it helps.
To check if you installed it correctly, you can use Qualys SSL Server Test at https://www.ssllabs.com/ssltest/index.html
I have installed a ssl certificate via WHM on one of my domain. Site is working with https://xyz.com.
However it is not working with https://www.xyz.com. I have checked the certificate and it is for www version as well. After some research it appears to be incomplete chain issue. I had no idea how to resolve this. Please help.
A certificate can contain a special Authority Information Access extension (RFC-3280) with URL to issuer's certificate. Most browsers can use the AIA extension to download missing intermediate certificate to complete the certificate chain. But some clients (mobile browsers, OpenSSL) don't support this extension, so they report such certificate as untrusted.
You can solve the incomplete certificate chain issue manually by concatenating all certificates from the certificate to the trusted root certificate (exclusive, in this order), to prevent such issues. Note, the trusted root certificate should not be there, as it is already included in the system’s root certificate store.
You should be able to fetch intermediate certificates from the issuer and concat them together by yourself. I have written a script to automate the procedure, it loops over the AIA extension to produce output of correctly chained certificates. https://github.com/zakjan/cert-chain-resolver
We purchased an SSL certificate through DNSimple and installed it on our Heroku SSL endpoint. Now navigating to the app via SSL works fine on Chrome and Safari, but Firefox shows a "This connection is untrusted" error. Why would an SSL cert be untrusted by Firefox only?
We figured out the problem:
The Heroku docs point to the following bundle.pem file, which DOES NOT WORK FOR FIREFOX:
https://knowledge.rapidssl.com/library/VERISIGN/ALL_OTHER/RapidSSL%20Intermediate/RapidSSL_CA_bundle.pem
The CORRECT bundle.pem file is at:
https://knowledge.rapidssl.com/library/VERISIGN/INTERNATIONAL_AFFILIATES/RapidSSL/AR1548/RapidSSLCABundle.txt
as indicated on the RapidSSL site.
Heroku docs need to be updated. Hopefully this saves someone else some time..
UPDATE: We reported this to Heroku and they updated their docs, so this is no longer an issue.
Mozilla include a list of Certificate Authorities (CA) with their products, as do Google, Apple, Microsoft and others. If your certificate can be traced back to one of these than the browsers will trust it. If not, you have to add an exception, or import the certificate into your browser.
The list of included CAs is created at the whim of the different browser makers. Some include the root CA for your certificate, and it seems Mozilla do not.
You can get a list of CAs included by Mozilla here. Check your certificate details. If the root CA is on this list file it as a bug with Mozilla. If it's not you could try asking them if they'll include it for the next release.
It's a problem of rapidssl but not yours.
you should not only provide the server certificate, but should concat your server certificate and INTERMEDIATE ca certificate.
do
$ cat ca_certificate.crt >> server_.crt
and restart your nginx.
you can find the ca certificate on what site you buy certificate.