Hi! When I try to run a GTmetrix scan analysis, the process is aborted and return this message:
Analysis Error
The SSL certificate for this site is not trusted in all web browsers
You may have an incorrectly installed SSL certificate. Check your SSL certificate at SSLShopper.
The certificate is not trusted in all web browsers.
You may need to install an Intermediate/chain certificate to link it to a trusted root certificate.
What's the URL you're checking? Being able to see the cert presented would help greatly. Do you get any errors when navigating to your site in a browser?
This part
means that you didn't create the full certificate chain with intermediary certificates. Are you using certbot? If so, which file are you pointing your web server to? You should have cert.pem, chain.pem, and fullchain.pem.
We could also use knowing what web server you're trying to configure to help you with anything related to server configs.
Web sites need to be configured to serve intermediate certificates which identify the certificate authority that issued the certificate. These are also called “chain” certificates; together with the end-entity certificate that identifies your web site, they form the certificate chain that allows someone connecting to the site to verify the path from a trusted root certificate authority to the site itself.
Forgetting to serve intermediate certificates can be a hard-to-notice and hard-to-diagnose problem because browsers often cache intermediate certificates that they’ve seen before and use them in case a particular site forgets to serve them. Thus, a misconfigured site can work fine in some browsers, but not others.
The way to serve the complete chain depends on what server software you’re using. When Let’s Encrypt issued your certificate, it gave you the appropriate intermediate certificate that needs to be served, but you might not have configured your web server to use it, or whatever software set up your web server for you may not have done so.
Thanks for sharing the tutorial that you followed.
The problem here appears to be the step where you upload the certificate data, where they leave the CA bundle field blank because of the user interface notice that
"In most cases, you do not need to supply the CA bundle because the server will fetch it from a public repository during installation."
Apparently this is incorrect in practice because the server apparently did not fetch the CA bundle from the public repository. Therefore, it would probably work better if you provided it. In this context, the CA bundle should be the same thing as the intermediate certificate or chain certificate. You might have this available as the 2nd item in fullchain.pem, or possibly in a file called chain.pem.
Thank you! Now I understand what you said.
I tried to generate a new certificate to get the 2nd item from fullchain.pem (it also generetad chain.pem).
But when adding the new certificate manually in my host, the message says “Private key doesn’t match the Certificate”.
Strange because I’m getting all new data from the just generated files (cert.pem, chain.pem, fullchain.pem, key.pem).
Please, how can I fix this incompatibility between Private key and Certificate when generating again?
Sure… I’m not using Certbot, but following the above Hostinger tutorial. On cert.pem:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
04:02:67:44:28:f5:0b:be:5f:2d:93:36:a8:b7:cc:0a:85:4e
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Let’s Encrypt, CN=Let’s Encrypt Authority X3
Validity
Not Before: Jul 25 17:49:00 2017 GMT
Not After : Oct 23 17:49:00 2017 GMT
Subject: CN=hotsale.com.br
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c6:d3:58:92:51:28:c9:6d:13:cc:de:33:0c:45:
58:d8:49:31:cc:ff:98:27:ff:bb:b1:a3:0b:7b:50:
86:59:b3:f6:e2:a0:a7:e0:5e:74:eb:13:c1:b8:6a:
92:7a:5a:5c:6b:a4:00:47:97:92:96:17:f8:c9:47:
4f:cb:9d:52:b0:de:32:86:bf:3e:17:c7:80:0a:e7:
ba:cc:10:4e:22:14:26:6c:3b:aa:e4:23:7e:16:38:
cd:8a:11:69:9e:2a:2f:1c:12:a5:a9:b9:c0:a6:93:
9a:16:63:ed:f2:22:cd:25:25:0c:9f:b9:17:e0:61:
f8:70:50:b6:3a:a2:dc:57:8c:37:0c:99:ee:f8:76:
7a:8f:46:f5:f1:8c:91:b2:7d:8e:ba:a2:31:f1:a0:
8f:91:86:81:d4:1a:19:70:b0:4c:94:43:84:d8:b5:
b1:49:bf:b7:cf:ca:03:b3:1a:77:bd:83:07:e2:22:
05:a9:fa:3d:f0:61:f6:ba:2b:dc:dc:00:fa:55:4d:
67:c0:7a:8e:5c:41:73:7d:f2:95:9d:fb:ca:f6:4c:
3b:96:fa:e3:c2:d4:49:4a:f8:78:b1:00:a5:aa:80:
98:44:9c:0d:1f:d2:8c:e9:56:2a:c0:d9:03:75:ae:
5e:a0:f7:81:49:bc:40:93:a0:49:81:8c:36:c3:d6:
0c:7f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
82:AC:46:4E:F9:4B:E5:00:F0:7F:2D:20:FE:69:3D:CC:B7:30:E5:C2
X509v3 Authority Key Identifier:
keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1
Authority Information Access:
OCSP - URI:http://ocsp.int-x3.letsencrypt.org
CA Issuers - URI:http://cert.int-x3.letsencrypt.org/
X509v3 Subject Alternative Name:
DNS:hotsale.com.br, DNS:www.hotsale.com.br
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.44947.1.1.1
CPS: http://cps.letsencrypt.org
User Notice:
Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at https://letsencrypt.org/repository/
Signature Algorithm: sha256WithRSAEncryption
85:bb:86:a7:42:84:c0:35:90:71:53:6a:73:09:29:ea:0a:24:
8c:91:af:c4:06:20:9a:e0:35:a1:59:2a:13:ed:1d:dc:d9:c9:
7a:4b:d1:62:55:aa:63:3a:c5:4e:9f:6e:55:00:d7:ef:6b:0d:
3b:74:60:c7:bc:b3:84:b4:26:cd:e5:15:dd:50:93:28:5a:33:
46:92:2a:b6:b4:7c:40:e9:80:2e:54:ad:de:83:03:c7:42:a6:
7b:96:59:18:4c:f0:ae:8f:8e:15:88:30:25:d1:b6:74:e4:36:
fa:5a:3c:d3:7a:11:0a:e4:4c:6f:73:31:83:ae:5f:71:f6:79:
b9:69:bf:51:be:6b:fc:9e:60:76:9c:09:db:22:29:77:f9:13:
6a:aa:03:70:e3:1b:da:d5:69:67:aa:3a:24:7b:a2:b7:82:82:
a1:9a:e6:10:59:40:57:89:13:6a:bf:19:d3:0e:11:d1:c4:3b:
cd:90:aa:bd:76:1f:d1:f5:ef:c0:93:9f:4e:92:29:a1:34:d9:
e8:aa:da:d6:fe:d1:5c:1f:62:1e:02:13:59:56:0d:d4:ec:aa:
a3:cc:8d:f6:37:83:58:98:aa:76:08:af:1e:c0:ce:3c:74:6d:
a8:a2:75:2f:61:1f:76:8a:20:df:b7:bd:d3:65:ac:56:94:dc:
d6:24:bf:d0
===========================================================
On key.pem:
That’s definitely a mismatch. The moduli of the corresponding public and private keys will always match. For some reason, that PHP-based ACME client they have you using is not saving the files as expected. You might try backing up and clearing out that directory, and running it again. A cursory look at the code indicates it looks at an ini file for configuration information - it’s possible something got messed up here.