IIS 8.5 building incorrect chain with Lets Encrypt Authority X3

1

Have something changed recently, lets encrypt certificates that are issued by Lets Encrypt Authority X3 doesn’t seem to be valid in Mozilla Firefox. It has worked with certificates that I have requested earlier that was issued by Lets Encrypt Authority X1.

Here’s the error from Mozilla Firefox (45.0.1) (It works fine in other browsers).

https://dev1.REMOVED.dk/ Peer’s Certificate issuer is not recognized. HTTP Strict Transport Security: false HTTP Public Key Pinning: false Certificate chain: -----BEGIN CERTIFICATE----- MIIE3zCCA8egAwIBAgITAPpcGo2ne5b7XzuLDIbSkPOlgDANBgkqhkiG9w0BAQsF ADAiMSAwHgYDVQQDDBdGYWtlIExFIEludGVybWVkaWF0ZSBYMTAeFw0xNjAzMjgw ODM2MDBaFw0xNjA2MjYwODM2MDBaMBgxFjAUBgNVBAMTDWRldjEudGlpbW8uZGsw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCqs2kdwaZYh/ppAffRqsui A9ar7M0Prli1QJX/y8YZAcil/KeszA7cUWMJTT/8juqMkuUF19eCxnzvX/zjw/hk 1wZAqEe89Gq75sE2AN9QlR4eHSU2UHawxnorkw1kTegz+x0V7cEFOE07TgbzGtN6 U/yssCtttwj/KelwAy7BoaEdeHdbtQnC5hq1LfnuHDThxUpygqJAVo8krruDjQCF pwmiPJFcdW9pfDoeu2xTCJUjbOujNVgcchbSK4tupDrfVOv9PZB7X4igmmIg+SWn PD042wbiTLFFR/jzg5HiWn2/lNgu7/pgndXVrRnCW9BcXPQ7/bZIPjwTqVKCW3IV AgMBAAGjggIWMIICEjAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUH AwEGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFLuKBGen6vTlsRfK +YzlQpaos9hVMB8GA1UdIwQYMBaAFMDMA0a5WCDMXHJw8+EuyyCm9Wg6MHgGCCsG AQUFBwEBBGwwajAzBggrBgEFBQcwAYYnaHR0cDovL29jc3Auc3RnLWludC14MS5s ZXRzZW5jcnlwdC5vcmcvMDMGCCsGAQUFBzAChidodHRwOi8vY2VydC5zdGctaW50 LXgxLmxldHNlbmNyeXB0Lm9yZy8wGAYDVR0RBBEwD4INZGV2MS50aWltby5kazCB /gYDVR0gBIH2MIHzMAgGBmeBDAECATCB5gYLKwYBBAGC3xMBAQEwgdYwJgYIKwYB BQUHAgEWGmh0dHA6Ly9jcHMubGV0c2VuY3J5cHQub3JnMIGrBggrBgEFBQcCAjCB ngyBm1RoaXMgQ2VydGlmaWNhdGUgbWF5IG9ubHkgYmUgcmVsaWVkIHVwb24gYnkg UmVseWluZyBQYXJ0aWVzIGFuZCBvbmx5IGluIGFjY29yZGFuY2Ugd2l0aCB0aGUg Q2VydGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vbGV0c2VuY3J5cHQu b3JnL3JlcG9zaXRvcnkvMA0GCSqGSIb3DQEBCwUAA4IBAQDNUm/JNAPCN8XmQSE6 qYjMDxxy+tghPf6MlRB3fgB/RmJUdWPTAys5hBpoKQUrgetjTbHhlY6su3zvczwo Uw09Z1aMxnf1H0Im5QtHKtSxpeMY8tjfL8x+7NA+cvBSiV6dr+TGKMy4fBFL/rcL MO6+sA1o1esGJrpC9FxDNZp/TJymgGXwDxmqGRdOiiWfXvIpUuZqdauo0geI0uZy DtDNuT0zG70JoRGlQ004okh/H34i6EBovqd8iELf9rcw6QsrzPsbg+zCbcibAf1A 5jrXaZOyR8QbCmO8HYnjJfZiTvBIr3BvrKuSSG2doPZscty4fo0qdowOSL/Hn9CZ zaAn -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIEqTCCApGgAwIBAgIRAIvhKg5ZRO08VGQx8JdhT+QwDQYJKoZIhvcNAQELBQAw GjEYMBYGA1UEAwwPRmFrZSBMRSBSb290IFgxMB4XDTE2MDMyMzIyNTkwNFoXDTM2 MDMyMzIyNTkwNFowIjEgMB4GA1UEAwwXRmFrZSBMRSBJbnRlcm1lZGlhdGUgWDEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtWKySDn7rWZc5ggjz3ZB0 8jO4xti3uzINfD5sQ7Lj7hzetUT+wQob+iXSZkhnvx+IvdbXF5/yt8aWPpUKnPym oLxsYiI5gQBLxNDzIec0OIaflWqAr29m7J8+NNtApEN8nZFnf3bhehZW7AxmS1m0 ZnSsdHw0Fw+bgixPg2MQ9k9oefFeqa+7Kqdlz5bbrUYV2volxhDFtnI4Mh8BiWCN xDH1Hizq+GKCcHsinDZWurCqder/afJBnQs+SBSL6MVApHt+d35zjBD92fO2Je56 dhMfzCgOKXeJ340WhW3TjD1zqLZXeaCyUNRnfOmWZV8nEhtHOFbUCU7r/KkjMZO9 AgMBAAGjgeEwgd4wDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAw HQYDVR0OBBYEFMDMA0a5WCDMXHJw8+EuyyCm9Wg6MHgGCCsGAQUFBwEBBGwwajAz BggrBgEFBQcwAYYnaHR0cDovL29jc3Auc3RnLWludC14MS5sZXRzZW5jcnlwdC5v cmcvMDMGCCsGAQUFBzAChidodHRwOi8vY2VydC5zdGctaW50LXgxLmxldHNlbmNy eXB0Lm9yZy8wHwYDVR0jBBgwFoAUwSZ0pIpEoOb6ICjYXCOaRYgYeeAwDQYJKoZI hvcNAQELBQADggIBAHODDwZVaO5EqEYoVvEPPzaZas5BNVRHUAdc+xNg4oKACBAW o3mnX1tKr9lsWSDxLrCE7y+mdRq37PKzapEaL1q8KYXgzI1Ua7JeyOvCs4IMmhSZ HLSJMFgAv77nD28kB6teMlJI+NxmvD5cmsDl+1C2D862DFuiy3R/80c++ZIqfWg3 CvsQmwx0bategh3cT8mPwQEdRW0LpgomT37kSxZSGn9TzPXQ+NSvD/CpEF0mVQWM 09aiOE3QWg8BpdzxpbbmEhtWv4MNU1U3iyYNjaPzqD1J3R/7IjJmsNbDY5XKoqIB AeHPisSzP8CdCwQpJC8rBDefUfrbYqvhWuCff+amrUe01nvp9jtWefwUWWSwcjEg xYwz2vt6TgLNw5wBWk854x6yc323se/Wp7u7F9lguCRIUMPVH9MfBzR1wyUfpbZa eFVPFkHQsKv5ydKNQlk8fO97xXhpK4yueMNLnjbWEDKnEvJtCsbqlQm3XHWvqhz9 B/V1c95n8Z9Av2uVZ5HvZKnA9OXi4WF1ES6hkiFzom/exWxBxd+skh6yJuX1edpX L5TSN5XTa5OPONWh3AQfz7/0aenJNhyPJ4687pwQpGir4ctvT1k3enSRNqO6Vwxv 0BB50f7tpC0k/XzGyQyCVXo6jjDv1057VbZTUB+Y7BzXvcm7aglHPA71K3nW -----END CERTIFICATE-----

2 Likes
2

You’re serving the Fake X1 Intermediate, not the Let’s Encrypt X3 intermediate that should be served.

Additional note: You can hide your domain, but you should know that it’s anyway visible in the certificate you posted.

2 Likes
3

I know my domain is in there. But I doubt bots will crawl it. Humans are welcome.

4

I can understand that for email addresses, but for domains? I guess your domain will be known to bots anyway, since all certificates are logged to CT and that’s publicly readable, even if your domain appears nowhere else.

5

Can you provide me with some more details, on how to fix that.

I request the certificates with https://github.com/ebekker/ACMESharp, the pfx files looks fine, from my knowledge

I install the certificate on the azure web app that host my site, and then I get that, error but only in Mozilla Firefox.

Here’s the registered certs in my Firefox

And in windows certificate store which IE and Chrome uses, I have both
Let’s Encrypt Authority X3 and X1

6

Your site is sending the X1 intermediate certificate with a certificate signed by the X3 intermediate.

Browsers that have not previously visited a site using the X3 intermediate certificate won’t have it cached locally and will fail to build the certificate chain that leads back to a trusted root certificate. That’s why it’s working in some browsers, and not working in others.

I’m not familiar with ACMESharp and not sure if this is a bug or not. Anyway, you can find the X3 intermediate certificate here.

7

Seems like it’s all correct now.

8

I’m having the same issue, what’s the fix?

FIREFOX 45.1 ERROR
www.xxx.xxx uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. The server might not be sending the appropriate intermediate certificates. An additional root certificate may need to be imported. Error code: SEC_ERROR_UNKNOWN_ISSUER
CHROME OK
SAFARI : UNTRUSTED CERTIFICATE

9

You’ll need to provide more details about your setup. What web server are you using? Which client did you use? How is your web server configured (certificate paths, etc.)?

Try running SSL Labs on your domain and see if it shows certificate chain errors.

10

Same client? Report it as bug on GitHub. It’s probably downloading a hardcoded intermediate or so.

In the mean time, you could either download the intermediate manually or use another client, see https://github.com/letsencrypt/letsencrypt/wiki/Links#windows.

11

I just activated Let’s Encrypt on my domain hosted on dreamhost.com
It’s an automated process and I don’t know what’s going on under the hood.
But I activated another domain last month and everything was fine, the only difference I’ve noticed between last month and today is in the issuer attribute, the certificate path is the same.

Last Month certificate:
Issuer: CN = Let’s Encrypt Authority X1
Certificate Path: DST Root CA X3/Let’s Encrypt Authority X1

Today certificate:
Issuer: CN = Let’s Encrypt Authority X3
Certificate Path: DST Root CA X3/Let’s Encrypt Authority X1

12

Please run SSL Labs against your domain. If the site reports certificate chain errors, then it looks like dreamhost has hardcoded the intermediate certificate, which is a bad idea for exactly this reason. I’m not familiar with their control panel, but if they don’t offer a way to change the intermediate certificate through it, you probably can’t fix this on your own and I’d recommend raising a ticket with them.

13

SSL Labs results:
Chain issues: Incomplete, Extra certs

14

Dreamhost.com does probably hardcode the certificate chain, if everything is automatic and you can’t do anything but activate / deactivate it, you should probably reach out to their support to correct the issue.

15

Yep, you’ll have to contact their support.

16

Maybe it is me noobing around, but I’m just trying to figure out where things go wrong in libraries I don’t own.

But as far as I can see the certificate response I get back from the ACME servers have the X1 intermediate certificate. Is that really how it is supposed to be?

If so, then ACMESharp has a bug that they are not able to replace it. Which I will report, but just want to be a 100% sure. Here’s a link to a certificate https://acme-v01.api.letsencrypt.org/acme/cert/03b829db51a4af2f6e4fa29c4025bdd40e08 that just requested, and it has the X1 intermediate.

17

That link leads to your certificate, not the intermediate certificate. The intermediate certificate is linked as part of the response header (last line):

curl -i https://acme-v01.api.letsencrypt.org/acme/cert/03b829db51a4af2f6e4fa29c4025bdd40e08
HTTP/1.1 200 OK
Server: nginx
Content-Type: application/pkix-cert
Content-Length: 1317
Link: </acme/issuer-cert>;rel="up"

https://acme-v01.api.letsencrypt.org/acme/issuer-cert leads to the correct intermediate certificate:

openssl x509 -in issuer-cert -inform der -text -noout
...
Subject: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3

I took a quick look at the ACMESharp source, and couldn’t find any hard-coded intermediate certificates and there is some code that downloads the rel=“up” link leading to intermediate certificates, so it looks like their implementation is correct. It’s possible there’s some non-obvious bug somewhere, so I’d suggest creating an issue anyway.

2 Likes
18

My guess is it’s downloading the intermediate but doesn’t replace it if there’s already one.

19

I had the same problem yesterday/today. The certificat chain I imported to the Microsoft Server has been ok. The server certificate is incuded as well as the Let’s Encrypt Authority X3 certificate.
As long as the Let’s Encrypt Authority X1 certificate is in the Certificate Store of my server the IIS delivers (in the chain as intermediate CA) the X1 certificate instead of the X3 certificate.
I had to remove the X1 certificate from the certificate store on my server. Now, it delivers the correct X3 certificate.
I analyzed the certificates X1 and X3 and found the following:
Both certificates have the same “X509v3 Subject Key Identifiers”:
A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1
You can easily verify that by using openSSL command for both certificates:
openssl x509 -in lets-encrypt-x1-cross-signed.cer -text
openssl x509 -in lets-encrypt-x3-cross-signed.cer -text
Because my Letsencrypt certificate references to this keyId, I assume, the IIS has problems to distinguish between both certificates:
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
Hope this helps to find the problem.

3 Likes
20

Yes, both certificates use the same key.