GTmetrix scan error on HTTPS

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.

When go to SSLShopper SSL Checker, the message is:

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.

Also https://www.ssllabs.com/ssltest gives me a “B” rating because:

This server’s certificate chain is incomplete. Grade capped to B.
This site works only in browsers with SNI support.

But scanning “letsencrypt.org” URL there is no error in both test mentioned above.
I saw one similar topic here, but I don’t know if it is the right solution for me:
https://community.letsencrypt.org/t/certificate-renewal-was-successful-but-old-date-still-appears-on-website-and-certificate-checkers/28012/5

Please, how can I fix my certificate to be accepted on GTmetrix and receive A grade on SSL test?

Best regards!

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.

Hi! Thanks for replying… The URL I’m checking is: https://hotsale.com.br

The SSL certificate was installed following Hostinger tutorial (my host):
https://www.hostinger.com/tutorials/ssl/how-to-install-free-ssl-from-lets-encypt-on-shared-hosting

When I was going to follow the instructions from Lets Encrypt site, the host support team told me to follow their own tutorial above.

Should I do all again but following Lets Encrypt tutorial instead?

Thanks!

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?

This incompatibility shouldn’t exist.

I obviously don’t want you to post your private key itself here, but can you post the output of running the following commands?

openssl x509 -in cert.pem -text -noout

openssl rsa -in key.pem -modulus -noout

(You said key.pem rather than privkey.pem, although Certbot would normally call this file privkey.pem.)

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:

Modulus=B8CFA7EB7FE4180633F4EA3B2D4ACAA062916156145131C5FFBE961CC287E435B20B9AF559334A799601789C9501214117731D62AAB1DAEFC109D4A331F29AD16DC50AB1DB7D7E1B7DBF2B101A2B24DD6F3A327606C8F26A9F53B64EE658441FC0482758CA2E502D566283FB99F6EECBAFEC96B32B2A019AD7971BDCC4870DC4D2FABF1E604F3356AB0515EEE89FA850810EEE736E30428935CBA7002B0AE6519554895DE7B31A613F3FFF70C7C3BD274700CDD6C9242AC4BD660D4BCC940F54C4FA9B02760D956514CAF5BFA548139E51AF1A228F8C554C756E494A5F9F59EC66A1379DE7BFEB20EA22A4A3E7800BC0FD11E1AA2656CF002E0C3E6BF69C8ABB

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.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.