[Help needed] Windows XP support

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?

user@sv1 [/home/user]# git clone 'https://github.com/jsha/sign-test.git'
user@sv1 [/home/user/sign-test]# ./script.sh
...
Error Loading extension section v3_ca
29796:error:2207507C:X509 V3 routines:v2i_GENERAL_NAME_ex:missing value:v3_alt.c:432:
29796:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:v3_conf.c:93:name=crlDistributionPoints, value=crldp_section
1 Like

but why was an entire TLD banned?

The script works perfectly here with OpenSSL 1.0.2d.

I’ll get on this later tonight, thanks for making this possible! A

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.

1 Like

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).

2 Likes

No, it isn’t because there is just one. I tried
nameConstraints=excluded;DNS:.mil
and that also does not work in XP.

2 Likes

Tested on XP64, with nameConstraints in cross.cnf comment out

What else to be done?

The following seem relevant to me:
http://unmitigatedrisk.com/?p=201
http://unmitigatedrisk.com/?p=198
and
http://www.serverbrain.org/certificate-security-2003/name-constraints.html

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.

1 Like

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.

One easy way to check is to look at what the chain engine is not happy with : http://unmitigatedrisk.com/?p=318

@jsha hit me up on skype if you need help.

Ryan

1 Like

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… :grimacing: Got the certificate in Chromiums store ánd /etc/ssl/certs (and did an sudo c_rehash ofcourse)…

Thank you @rmhrisk!

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.

1 Like

Ah, this forum omits things in angle brackets. Let’s try again…

“Missing Name Constraint for <Directory Address:CN=tk.davidearl.uk,O=TK,S=England,C=GB>”

how about just recommending Firefox? that way your site doesnt have to be a security hol in the internet due to old standards.

1 Like

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.

@My1 that would be fine if you knew who your users were, but a general web site can’t know that. Also, unless they start in http, you can’t even tell them anything, because all they get is a frightening message about someone trying to attack them before we have any opportunity to communicate with them, or drop back to http. It’s not even like a self-signed certificate - the browser simply won’t let the user proceed at all. So if, for example, someone follows a link in an email or another web site, or a Google search (which probably covers 90% of the cases!), as far as they are concerned it is a web site that just doesn’t work, when other similar sites do work because they got their certificate elsewhere.

In 5 year’s time maybe XP will be at such a low level that it is discountable, but as Facebook and Twiiter have been demonstrating recently, they think a big enough proportion of their traffic is coming from XP that they can’t afford to drop support for it.

Having said that, my site visitor who hit this for real is in California and should know better. But maybe his PC is one that isn’t able to be upgraded for whatever reason. In this case I do actually have contact with many of the people who use that site, but that’s not the point - it’s about the ability of LE to work peoprly on the wider anonymous internet where XP is still at 10 or 15% of the market worldwide.

I don’t think Microsoft is going to care about (helping out with) some bugs in their software for which mainstream support ended on April 14, 2009…

No, of course they aren’t going to change anything, but someone might be prepared to help us understand the NameConstraints logic on XP. (There may also be XP documentation out there too which I haven’t found yet).

as I said maybe when you declare whats not perimtted, you have to declare what’s permitted, so try to declare “allow all” and “forbid that tld that for no reason I can imagine has been blocked from LE”.