Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Background: I have a website which has, for a particular subdirectory, client certificate mapping set up in IIS6 for download of certain privacy-protected files. There are two independent clients that use the download, and it was all set up and working nicely as of several months ago. Server's SSL certificate and client digital ID certificates all provided by Verisign.

Then, one of the client certificates expired, of course. I downloaded the public certificate from Verisign again like last time, installed the new (more bits!) intermediate certificate and the client certificate shows as "valid" on the server. The client side (an ocean away) also installed the new intermediate certificate and shows as valid on the client side. Did what we did to make it work before, right? Except the new client certificate has always thrown a 403.16 error, "Client certificate is ill-formed or is not trusted by the Web server."

Going over and over the certificates, I have noticed that the new one has a line that reads "OU = Digital ID Class 1 - Netscape Full Service" where as both the old expired one from this client and the still-working one for the other client read "OU = Digital ID Class 1 - Microsoft Full Service". So, what is the difference? Will using a Netscape digital ID that you have somehow installed into IE (what I suspect is happening) cause exactly this problem? The client says they have talked to Verisign and Verisign said they are "the same". Uh huh. If they are so much the same then why is the first step in signing up for a Verisign digital ID to choose either IE or Netscape?

Pointers to some documentation on this issue would be appreciated. I can't seem to google up any. Is this because most people realize that installing a Netscape certificate into IE probably won't work?

I have my own client certificate that is not provided by Verisign, which I have been able to install appropriate intermediate certs and make work for this subdirectory/mapping as a test - but I'm pretty sure that if there's a choice between IE and Netscape types of certificate, this particular organization providing the certificate would have chosen IE. I used IE6 for this testing.

share|improve this question
    
You'll probably need to include more information. IIS version? web client versions? gated cert etc? Does this apply: kb260266 –  cwheeler33 Jan 18 '11 at 19:33
    
Hmm, kb260266 does not seem to apply and the server's SSL cert lists only Server Authentication and Client Authentication as Enhanced Key Usages so no gated cert, it would appear. The server is IIS6 and its certificate runs July to July so shouldn't be a factor here. My testing of my own client cert uses IE6. I believe the other clients are also using IE, I've asked them to confirm. –  Henry Harper Jan 18 '11 at 19:58
    
Have YOU discussed this with Verisign? What was their response? –  John Gardeniers Jan 18 '11 at 20:30
1  
There are different ways of storing a certificate in a file (mainly DER and Base64). Windows and related software tend to use DER; everyone else uses Base64 (gross generalization, but mostly true). If the browser loads the cert then it's working. If the server rejects the cert it's related to the server configuration; Verisign should be able to provide you with the details on how one or the other should be configured. –  Chris S Jan 18 '11 at 20:32
    
I've been reluctant to contact Verisign because I don't have a 'direct' relationship with them - I am not the person who paid for the digital ID, and my server certificate came through the large organization (of which I am not a direct employee). But perhaps that time has come, I will see what they say. Both old and new certs from this client are Base64 (start with -----BEGIN CERTIFICATE----- when opened in text editor) and SSLDiag doesn't report a problem with the server cert, client cert or mapping. –  Henry Harper Jan 18 '11 at 21:23
show 2 more comments

1 Answer

And in this case the answer is, "it doesn't matter, because the intermediate certificate has not been correctly installed". Exactly like in http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/bb089a80-c8ba-4004-9c0f-f10fb6b36416.mspx?mfr=true - the "certificate wizard" isn't smart enough to put the intermediate cert in the proper place without hand-holding. Even though the client certificate shows as valid when opened on the server, and even if SSLDiag shows the client certificate mapping as OK. I had trimmed some expired intermediate certs because of something else I read about limited header space to list valid certs for negotiation, and thought that I saw the new intermediate G3 cert in the store in MMC but it just wasn't there until I clicked through all the boxes to "show physical store" in the wizard.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.