In https://github.com/letsencrypt/letsencrypt/issues/1660 there is some information suggesting that the Name Constraints on our cross-signed certificate from IdenTrust are the reason IE and Chrome on Windows XP don’t support Let’s Encrypt certificates. I’d like to enlist some help from the community in testing that hypothesis. If you’re interested in volunteering, please try this:
Create a CA cert and intermediate with the same fields as our intermediate. There are some scripts that should get you a good start here: https://github.com/jsha/sign-test.
Add that CA cert to the trust store on a Windows XP box. I’m not sure how to do this, you’d need to look up documentation.
Issue an end-entity cert from the intermediate you generated, and provision it on a web site.
Visit that web site in IE and Chrome on the XP box. Verify the site is not trusted, and that the error messages matches the message in #1660
Repeat steps 1-4, but without the NameConstraints fields in the intermediate. Is the certificate trusted?
If the certificate is trusted in #5, try adding back the NameConstraints, plus an explicit Permitted field as suggested by intgr here. Is the certificate trusted?
If #6 is true, we may be able to make things work on XP. Please save the certificates from each step so others can check them too.
Thanks very much for your help, if you are able to give it!
Is there a reason why you added the all-zero’s IP addresses to the Name Constraints? I couldn’t find them in LE’s X1 certificate… Would it make a difference?
I prepared those scripts against an earlier version of the cross-sign that included a Name Constraint forbidding IP addresses. The final revision removed that Name Constraint (though we don’t issue for IP addresses). The scripts probably do need some updating to match the final version of the intermediate, sorry about that! In particular it makes sense to remove the IP address constraint, as you said.
Select “Certificates” and press “Add” again, followed by for example “Computer account” in the next screen and “Local computer” (makes the most sense I guess) and press “Finish”
Press “OK”
Open the Certificates Snap-in
Press the right mouse button on one of the folders and go to “All Tasks” -> “Import”
“Next” -> select root.pem (the file selector doesn’t recognise *.pem files automatically, but you can just type in the file name if you’re in the right directory… It’ll recognise it.) -> Next -> “Place the certificates in the following store” -> Trusted Root Certification Authorities is most logical I think… -> Next -> Finish
Done.
The segfault aparently comes after I sign one cert and try a second… Clearing the DB helps
Now I get an “The security certificate presented by this website was issued for a different website’s address.” in XP for some reason…? Well… Tomorrow another day…
You would have to provide more detailed instructions abount point number one - how to generate intermediate certificate that has same fields as yours. Why make us do guess work if you obviously have that data?
I’ve gone through the process to create my own local CA and intermediate, and yes, adding
nameConstraints=excluded;DNS:.mil,excluded;IP:0.0.0.0/0.0.0.0,excluded;IP:0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0
to the config file for setting up an intermediate certificate produces exactly this error on XP (Chrome).
My speculation in the GitHub issue that it was just the apostrophe in the Org name that was confusing XP was wrong.
I did try setting it up the certificates without the nameConstraints line first and then changed only that one line and recreated everything again from scratch, so it has to be just that one line that makes the difference between it working and not.
Since the steps are set out in minute detail here: https://jamielinux.com/docs/openssl-certificate-authority/introduction.html I followed exactly that to the letter, except for replacing with my own domain name, and adding the nameConstraints on the second attempt. I created a new Debian Jessie virtual machine for the test, so there shouldn’t have been anything else on the machine that would have influenced the process.
I also checked my CA->intermediate->domain chain DOES work on the same version Chrome on Windows 10 (I didn’t install the root, but it just tells you it’s not safe but lets you proceed, just like a self-signed, whereas XP produced the error illustrated and prevents you proceeding altogether.
I can’t see where in https://www.openssl.org/docs/manmaster/apps/x509v3_config.html it allows “…,excluded”. However, I also tried
nameConstraints=excluded;DNS:.mil;IP:0.0.0.0/0.0.0.0;IP:0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0
and that didn’t work either. I wonder if XP doesn’t like more than one (none of the examples in that reference above have more than one).
These all seem to suggest that XP (uniquely, and contrary to the relevant RFC) requires a DirectoryName directive when NameConstraints is used, though all the examples are in relation to permitted not excluded. I’ve asked the author of the first post above if he can shed any light.
Post 24 and 28 on my blog are relevant also (can’t link due to forum rules).
Though I did not do tests with excluded the same code path would surely be used, I would bet good money your issue is with the DirectoryName directive.
I can’t even get the leaf certificate to work in Chromium on my modern desktop, although Firefox and openssl s_client don’t have a problem with it… Got the certificate in Chromiums store ánd /etc/ssl/certs (and did an sudo c_rehash ofcourse)…
On XP, the INTERMEDIATE certificate in my test has Extended Error Information, which I;d not noticed before, which says “Missing Name Constraint for <Directroy Address:CN=tk.davidearl.uk,O=TK, S=England, C=GB>”
which is more evidence that it is to do with DirectoryName. I’ll see if I can construct a test case that works, with DirectoryName in it, which if successful hopefully should inform what is needed with the LE certificate.
So, I’ve tried just about every combination I can think of and been unable to get it to work on XP. It’s not helped by the almost complete absence of documentation. OpenSSL basically just puts what you tell it in the certificate and doesn’t much care what it is so long as it is syntactically correct, so it’s how XP interprets the NameConstraints that matters.
I think it is pretty certain now that if you have NameConstrants on DNS, XP alos requires you to have a NameConstraint on DirectoryName (aka dirName as far as OpenSSL is concerned). I’ve got as far as a certificate chain that shows no errors in the individual certificates but XP still objects in the same way.
I tried Excluded for dirName, but that doesn’t work. However, it also doesn’t work in Windows 10. This seems to me to indicate that you have to have a Permitted for it to work (and adding that does indeed then work on Windows 10). But to do that the dirName (the entire set including CN) has to be allowed at the root, so the root would have to know what the sites were it was going to authorize, clearly completely impractical in this situation.
I ended up with a script which set up a private authority form scratch each time, then an intermediate via a CSR, then a leaf certificate, and installed it, based around a single openssl config file, so it wasn’t too hard to tweak each time.
I think it needs someone from Microsoft probably needs to be involved at this point.
But at the moment it’s looking to me like either that NameConstraint has to come out altogether, or it isn’t going to work on XP ever.