Upcoming intermediate changes

We’ve been working on fixing Windows XP support for Let’s Encrypt certificates. We’ve got new intermediates issued from IdenTrust that we’ll be testing out today and rolling out if everything is good. We’re also rolling out a new untrusted fake root and fake intermediate on the staging server.

The new trusted intermediates will be called “Let’s Encrypt Authority X3” and “Let’s Encrypt Authority X4,” and will be in the CT logs and on our web site. The new untrusted intermediates will be “Fake LE Root X1” and “Fake LE Intermediate X1.” If you see a certificate from one of the untrusted intermediates on a live website, it was issued against the staging server and should be reissued against production if you want it to be trusted.

If you’re happy with your end-entity certificates, you don’t need to do anything. The next time you renew them, the new certificates will be trusted by Windows XP. If you want support for Windows XP, wait for an update on this thread announcing that the new intermediates are installed, then renew your certificates.

It’s worth noting that “Let’s Encrypt Authority X3” and “Let’s Encrypt Authority X4” will have the same public keys as “Let’s Encrypt Authority X1” and “Let’s Encrypt Authority X2,” respectively. We issued the new certificates using our existing keys so that we would not have to delay Windows XP support until our next key ceremony (currently unscheduled).

Browsers and other TLS clients generally validate certificate chains based on both the issuer public key and the issuer name. So when you renew your certificates, it’s important to serve them with the correct certificate chain. If you’re using the official client you should be fine. Similarly, if your client correctly uses the Link: rel="up";title="issuer" header received on issuance, you won’t have any issues. The only place you might expect to have issues is if you hardcoded the certificate chain somewhere. If that’s the case, you should update your code to use the issuer certificate provided at issuance time.

Similarly, OCSP responses for certificates issued by Let’s Encrypt Authority X3 will be signed by Let’s Encrypt Authority X3. For end-entity certificates already issued by Let’s Encrypt Authority X1, the OCSP responses will continue to be signed by Let’s Encrypt Authority X1 until the end-entity certificate expires. If you do manual validation of OCSP responses, make sure that you are validating based on the correct issuer certificate for the end-entity certificate, not based on a hard coded issuer certificate.


This work is done. Newly-issued certificates will be compatible with Windows XP.


The change in the new intermediate certificate is that the NameConstraints extension was removed.

In X1 and X2, there was a NameConstraints forbidding the intermediate from issuing for .mil domains. As a simplification for the sake of this post, let’s say this was represented as Deny=.mil. Note that this form has no Allow.

Windows XP has a bug in the certificate verification code, where if no Allow clauses are present, XP assumes that the certificate is valid for no names at all. Any certificate issued under such an intermediate would work on every system except Windows XP, as systems that do not understand NameConstraints at all would ignore it.

Let’s Encrypt Authority X3 is almost the same as Let’s Encrypt Authority X1 - they have the same keypair, it’s just that the NameConstraint has been removed. Same with X4 and X2.

There is no concern about allowing weaker ciphersuites or hash algorithms, because XP SP3 has support for SHA256. Let’s Encrypt has never issued any SHA-1 certificates, and never will.


One additional piece of clarification: the default cipher suites and protocols configured by the Let’s Encrypt client are not compatible with Windows XP. If you need to support XP users, you will want to use the “Old” settings from Mozilla’s TLS configuration page. There is not currently an option in the Let’s Encrypt client to configure those options. You will have to manually configure them.