[Help needed] Windows XP support

82

"Important
The default policy of a Microsoft client validating a certificate with name constraints asserted is that all names have to be explicitly permitted. For example, if a name constraint does not specify the e-mail name as a permitted type, and a certificate request contains an e-mail name, the request will be rejected. It is possible to relax this policy and implicitly allow names not defined in the name constraint extension by configuring the CA policy in the registry."
From: https://technet.microsoft.com/en-us/library/cc737026(v=WS.10).aspx

As I see it, that is happening because the Name Constraints have the Excluded Field set but the Allow Field is None, so because how the Name Constraints have to be Explicitly permitted, this will fail. A workaround is to change that on XP Registry which I think is pretty fair as XP is like a Fossil. Or LE could have besides the Excluded ‘.mil’ TLD have all other TLD in the world, explicitly permitted in the Allow Field, your call buddy!

Edit: I tried to find where I could change that behavior as the MS doc said, but I couldn’t, here is where I think it should be: https://msdn.microsoft.com/en-us/library/windows/desktop/aa380258(v=vs.85).aspx#certificate_chain_structures
Maybe I lack the understanding to get this information.

2 Likes
83

Useful, fweno84.

However, there is a note below that section:

“If you do not specify permitted or excluded names, you are creating a wildcard (*) name constraint for those name constraint formats.”

Perhaps an explicit wildcard (*) is needed for the permitted field on XP.

84

I’m using a similar setup for testing.

Two things: You don’t need to send the ISRG Root X1. When it’s included in the client, the client will obviously have it anyway, and right now it’s not trusted anyway. In both cases there is no point in sending it.

Second, there is broken software out there that will fail to connect if the first chain is not valid. It’s better to swap these around so that the valid chain comes first and the ISRG Root X1 chain is second.

85

The root is not needed indeed, but as SSLLabs doesn’t recognises it, I added it for the sake of chain verification. :slightly_smiling:

The thing about the chain order I didn’t know, thnx :smile:

86

@fweno84 @dxpack
by the way I already theorized this long ago.
but I got pretty much ignored.

1 Like
87

I was ironic about changing the field in the LE Root certificate. I don’t think this is even possible or viable. But as I understand, because the LE Root has Name Constraints set up, all other Certificates that follow will need that the LE Root explicit Allow things. My point is that a resolution from LE side is way more difficult…

88

Sure. But as noted, it appears that blank fields should be considered as wild card (i.e. allow all, deny .mil). It may be the case that an explicit wild card is required for XP.

I haven’t dug into the link you sent in detail, nor have the ability to attempt to model an explicit wild card cert. Might be worth someone giving it a shot.

1 Like
89

it isnt in the LE root and not in the IdenTrust root as well.
simply said it is the intermediate, which is below the root and can be changed easily enough if needed, provided IdenTrust would sign that.

90

I found this .htaccess code byJiří Zralý
(medhi on Github):

https://gist.github.com/medhi/25368643e33d650630cb

It has worked in my case
the xp sp3 machine next to me is not redirecting to https
the 7 pro machine I’m on redirects in chrome,firefox, and ie11

1 Like
91

That’s a good solution for filtering your users as long as the SSL isn’t required for keeping the information secure.

Another tip is to direct Google to the http:// page as the page’s canonical address, even for SSL URLs. This way, Google lists the non-SSL page in its results and any clicks are upgraded to SSL as required. Again, not very useful for sites using HSTS or for transmitting credit card details, etc but good enough for a brochureware site.

92

@bb1
I dont think IEXP does HSTS in the first place, not forgetting thatunless a site is visited via HTTPS AND trusted, HSTS wont enable.

@jackpixley you might consider also redirecting firefox even on XP since firefox does its own security and should have no problem whatsoever in LE certs.

@ both of you:

be advised that this is susceptible to MITM, because of the flash of HTTP at the start.

93

Also, google penalizes sites that arent https

96

So back to topic...
There are good news:

Certificate Compatibility with Windows XP

ETA: Before March 22, 2016

A bug in Windows XP causes parsing of our current cross-signature
from IdenTrust to fail. We will be correcting this by getting new
cross-signatures from IdenTrust which work on Windows XP.

9 Likes
97

can’t wait! this will improve adoption rates for sure

98

Awesome news @rugk :thumbsup:

100

Any details about the new CA cert? Should I start the renewal process ? :smiley:

101

We’ll post when it’s ready. It’ll be soon, but we probably won’t quite hit the estimated date of March 22.

1 Like
102

Do you have any ETA? So, is it like early April, middle April, early May, what?

103

Thank you for letting us know.
Cheers

104

I would say probably early April.

1 Like