The ts command is to create requests, sign requests and verify timestamps according to RFC3161. So the exercise I was trying to demonstrate at work was to create a certificate for the purpose of timeStamping (critical extension timeStamping on the cert) to sign digests into a token.
The verify function was just to demonstrate that the part of the process that was failing (verifying the token) was actually verifying the certificate. It had not even gotten to the stage where it would verify the token. The reason we use command-line utilities to verify is for transparency. Data could be used in the courts for example and having that "hey.. go download openssl and verify it yourself" is a lot better than.. here is a util we wrote to verify the token. WHAT? Your util? sure..... So the issue with ignoring those extensions within your own app will probably work for you depending on your situation. In my case, it is not really an option. I'm not really sure why this particular extension is marked as critical. It does seem a bit weird. Microsoft aren't exactly the most compliant company out there when it comes to some industry standards... Brad -----Original Message----- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Randy Turner Sent: Thursday, 4 June 2009 1:07 AM To: openssl-users@openssl.org Subject: Re: Problems verifying certificates generated by Microsoft Certificate Authority and timestamping Hi Brad, I guess I'm going to have the same problem (Microsoft CA generating certs I have to verify with OpenSSL). I wasn't aware of the "ts" command, but I'm assuming that I can always verify MS-CA certificates if I do this programatically, using the openssl api. I will have to verify timestamp as well as other general identity certs, but I will always do this from custom software using the openssl API, and not using interactive command line utiliities. If there are any issues ignoring critical extensions programatically, then please let me know. I'm not sure why Microsoft is marking these extensions as critical. Randy On Jun 3, 2009, at 12:35 AM, Brad Mitchell wrote: > <!-- /* Font Definitions */ @font-face {font-family:Tahoma; > panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, > li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font- > size:12.0pt; font-family:"Times New Roman";} a:link, > span.MsoHyperlink {color:blue; text-decoration:underline;} > a:visited, span.MsoHyperlinkFollowed {color:purple; text- > decoration:underline;} pre {margin:0in; margin-bottom:.0001pt; font- > size:10.0pt; font-family:"Courier New";} span.EmailStyle18 {mso- > style-type:personal; font-family:Arial; color:windowtext;} > span.EmailStyle19 {mso-style-type:personal-reply; font-family:Arial; > color:navy;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in > 1.0in 1.25in;} div.Section1 {page:Section1;} --> > For anyone that cares. > > > > I ran: > > > > certutil -showreg policy > > > > which gave me the registry entry for cert policies: > > > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc > \Configuration\LUCINDA ROOT CA\PolicyModules > \CertificateAuthority_MicrosoftDefault.Policy > > > > I modified the multi-string value: DisableExtensionList > > And added: > > > > 1.3.6.1.4.1.311.21.10 > > > > MS CA no longer adds this extension to certificates it produces. > I'm not sure what the long term affects of this would be in an > enterprise but this is what I've done to remove it. > > > > brad > > From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org > ] On Behalf Of Brad Mitchell > Sent: Wednesday, 3 June 2009 11:15 AM > To: openssl-users@openssl.org > Subject: Re: Problems verifying certificates generated by Microsoft > Certificate Authority and timestamping > > > > Hi, > > > > I've been trying to get Time Stamping working where the CA issuing > the Time Stamping certificate is issued by a Microsoft Windows > Server 2003 Enterprise CA. > > > > I've had success in terms of being able to actually sign the digest > and I actually have a certificate with the purpose of Time Stamp > Signing as YES. > > > > I am however having issues when I try to verify a token against the > certificate. > > > > error 34 at 0 depth lookup:unhandled critical extension > > > > This also happens when: > > > > openssl verify -Cafile ca.cer tsatest.cer > > > > tsatest.cer: /C=AU/ST=NSW/L=Sydney/O=Test TSA/OU=TSA/CN=Mr Test/ > emailAddress=tes > > t...@test.com.au > > error 34 at 0 depth lookup:unhandled critical extension > > OK > > > > Sure I can get this to ignore the critical extension: > > > > openssl verify -ignore_critical -CAfile ca.cer tsatest.cer > > tsatest.cer: OK > > > > There is no way however to do this using the "ts" commands for > verifying RFC3161 tokens/responses. > > > > Whilst I could modify the ts.c and set the ignore_critical flag in > the X509 STORE, according to RFC3280. > > Line from the verify help page for openssl: > > > > "Normally if an unhandled critical extension is present which is not > supported by OpenSSL the certificate is rejected (as required by > RFC3280 et al). If this option is set critical extensions are > ignored." > > > > I'm guessing this has something to do with these stupid application > extensions it has put on the certificate when generated from the > Microsoft CA: > > > > > > X509v3 Basic Constraints: critical > > CA:FALSE > > X509v3 Key Usage: > > Digital Signature, Non Repudiation > > 1.3.6.1.4.1.311.21.7: > > 0..&+.....7.....Y....../...z.....=...z...@..d... > > X509v3 Extended Key Usage: critical > > Time Stamping > > 1.3.6.1.4.1.311.21.10: critical > > 0.0 > > > > Does anyone out there have any experience with generating > certificates from Microsoft CA without these unknown extensions? > > > > I'm guessing in this case it's the 1.3.6.1.4.1.311.21.10. > > > > Application Policies extension -- same encoding as szOID_CERT_POLICIES > szOID_APPLICATION_CERT_POLICIES 1.3.6.1.4.1.311.21.10 > > > ^^ from some Microsoft page. > > > > Any ideas?? > > > > Thanks, > > Brad > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.339 / Virus Database: 270.12.46/2142 - Release Date: > 06/02/09 17:53:00 > No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.51/2151 - Release Date: 06/03/09 05:53:00 ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
