Wildcard cert invalid on some tablets

I use the certes acme implementation (https://github.com/fszlin/certes) and I thought I had wildcard certificate creation working, but some tablets show ‘cert authority invalid’. If anyone could look at the cert and let me know what I did wrong I would appreciate it very much.

My domain is https://guildtag.com

Server is Running IIS10.

Here is the cert I am currently using:
https://crt.sh/?id=1196678523

Hi @grimiz

your certificate is good ( https://check-your-website.server-daten.de/?q=guildtag.com ):

CN=*.guildtag.com
	12.02.2019
	13.05.2019
expires in 71 days	*.guildtag.com, guildtag.com - 2 entries

Both connections (non-www and www) use that certificate:

Domainname Http-Status redirect Sec. G
http://guildtag.com/
142.11.211.218 303 https://guildtag.com/ 0.270 A
http://www.guildtag.com/
142.11.211.218 301 https://guildtag.com/ 0.270 E
https://www.guildtag.com/
142.11.211.218 301 https://guildtag.com/ 2.457 B
https://guildtag.com/
142.11.211.218 200 2.780 B

And you have correct redirects.

Same with Ssllabs:

https://www.ssllabs.com/ssltest/analyze.html?d=guildtag.com&hideResults=on

Grade B.

You have enabled RC4, you should remove that. But that isn't a problem with "cert authority invalid".

One thing I don't understand checking the SSLLabs result:

Path #1: Trusted
1 Sent by server *.guildtag.com
Fingerprint SHA256: 14f27ef88e639d2c2e0c62d54b78d62041b975133e108cc423370356374a69f2
Pin SHA256: JQjsp6MgtJAfHWN1N3wNdwCKcNlaadIlwRfjUjWMDm8=
RSA 2048 bits (e 65537) / SHA256withRSA
2 Sent by server Let's Encrypt Authority X3
Fingerprint SHA256: 731d3d9cfaa061487a1d71445a42f67df0afca2a6c2d2f98ff7b3ce112b1f568
Pin SHA256: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
RSA 2048 bits (e 65537) / SHA256withRSA
3 In trust store ISRG Root X1 Self-signed
Fingerprint SHA256: 96bcec06264976f37460779acf28c5a7cfe8a3c0aae11a8ffcee05c0bddf08c6
Pin SHA256: C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=
RSA 4096 bits (e 65537) / SHA256withRSA
Path #2: Trusted
1 Sent by server *.guildtag.com
Fingerprint SHA256: 14f27ef88e639d2c2e0c62d54b78d62041b975133e108cc423370356374a69f2
Pin SHA256: JQjsp6MgtJAfHWN1N3wNdwCKcNlaadIlwRfjUjWMDm8=
RSA 2048 bits (e 65537) / SHA256withRSA
2 Extra download Let's Encrypt Authority X3
Fingerprint SHA256: 25847d668eb4f04fdd40b12b6b0740c567da7d024308eb6c2c96fe41d9de218d
Pin SHA256: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
RSA 2048 bits (e 65537) / SHA256withRSA
3 In trust store DST Root CA X3 Self-signed
Fingerprint SHA256: 0687260331a72403d909f105e69bcf0d32e1bd2493ffc6d9206d11bcd6770739
Pin SHA256: Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys=
RSA 2048 bits (e 65537) / SHA1withRSA
Weak or insecure signature, but no impact on root certificate

There are two paths. One is complete, one requires an extra download. But the certificate is the same.

Do you have different vHosts domain / *.domain?

Do you have a screenshot?

It’s using the intermediate signed by ISRG Root X1, so many old clients won’t trust it.

I don’t know how to make IIS switch to the intermediate signed by DST Root CA X3.

2 Likes

Thanks, didn't see the difference. That's curious: Checked one of my own subdomains there is only one path

Path #1: Trusted PIN
1 Sent by server *.server-daten.de
Fingerprint SHA256: 0f7e38e50d71fd90f193ecff9f92df3671b331eaf5a13eca8a3981cd7953f117
Pin SHA256: xdIR8weEDpcQExQNLv6PygFoSBUFNgZQxaM8fIWpyp4=
EC 384 bits / SHA256withRSA
2 Sent by server Let's Encrypt Authority X3
Fingerprint SHA256: 25847d668eb4f04fdd40b12b6b0740c567da7d024308eb6c2c96fe41d9de218d
Pin SHA256: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
RSA 2048 bits (e 65537) / SHA256withRSA
3 In trust store DST Root CA X3 PIN Self-signed
Fingerprint SHA256: 0687260331a72403d909f105e69bcf0d32e1bd2493ffc6d9206d11bcd6770739
Pin SHA256: Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys=
RSA 2048 bits (e 65537) / SHA1withRSA
Weak or insecure signature, but no impact on root certificate

I create the pfx - file with the Letsencrypt certificate and the DST intermediate

Fingerprint SHA256: 25847d668eb4f04fdd40b12b6b0740c567da7d024308eb6c2c96fe41d9de218d

How does certes create the pfx - file?

I’ll gladly admit most of the cert generation process/details goes right over my head - I’ll try provide any info you need as far as I understand it :slight_smile:

I also use the v1 non wildcard cert generation on my site to support custom domain names for my SaaS platform.

Here is my c# code that generates the pfx.

        var privateKey = KeyFactory.NewKey(KeyAlgorithm.RS256);

        var csr = new CertificationRequestBuilder(privateKey);
        csr.AddName($"C=US, ST=PA, L=Pittsburgh, O=Keenmade, CN=*." + webCert.Domain);
        csr.SubjectAlternativeNames.Add(webCert.Domain);
        //csr.SubjectAlternativeNames.Add("*." + webCert.Domain);
        
        var csrBytes = csr.Generate();

        var finalize = await order.Finalize(csrBytes);
        var certChain = await order.Download();

        Console.WriteLine("Exporting Cert");
        // Export Pfx
        var pfxBuilder = certChain.ToPfx(privateKey);
        var pfx = pfxBuilder.Build(webCert.Domain, "**********");

Not sure if this helps, but here is a screenshot of the intermediaries I have installed on the server.

I don’t know if this is relevant.

But do you have the intermediate certificate in your webhosting certificate store?

I don’t know if IIS sends certificates from another folder.

PS: Add the intermediate certificate to Webhosting and recheck your domain.

That didn’t fix it, but I just checked my non-wildcard certificates that use v1 and even they are not working on older tablets… I need to revisit my code and see if there is something I missed. I’ll ask on the certes project site since the problem seems to stem from that code.

Thanks for your help.

Rechecked my code.

I don’t use the intermediate certificate to create the pfx - file, that’s wrong.

The code splits the file from Letsencrypt to get only the domain certificate. With that the .pfx is created.

So I have no idea why I don’t have the same problem.

Only idea: The intermediate certificate in webhosting.

But I can’t check that and remove this certificate :wink:

Or a reboot is required to activate that / change the source of the intermediate certificate.

I removed the old X1 intermediate certs from the server and then rebooted and the issue is resolved!

1 Like

Thanks, good to know.

And Ssllabs shows now only one certificate path.

So if these tablet-users don’t have problems, then it’s the solution.

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