>From: owner-openssl-us...@openssl.org On Behalf Of Seth Rice >Sent: Tuesday, 16 July, 2013 17:59
>I'm running OpenSSL 1.0.0-fips 29 Mar 2010. I made a jump from >a 2009 build yesterday and noticed my scripts were returning data >that I didn't expect to see. >It turns out that openssl now replies with something I'll call the >"depth header". This is data that I can't seem to suppress from being shown. These are the verify-callback "trace" only for s_client (and s_server if client-auth, rare). They are not new; the oldest openssl I have to hand, 0.9.8g from 2007, has them. >I have a script that pulls the expiration date and common name from >a cert. The common name part is what's throwing me now. for example, >if I run... >echo -n '' | openssl s_client -connect google.com:443 | >awk 'BEGIN { p = 0 } /BEGIN CERT/ { p = 1 } { if (p) print $0 } >/END CERT/ { p = 0 }' | openssl asn1parse | grep T61STRING >I get... >depth=2 C = US, O = Equifax, OU = Equifax Secure Certificate Authority >verify return:1 >depth=1 C = US, O = Google Inc, CN = Google Internet Authority >verify return:1 >depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com >verify return:1 >DONE > 234:d=5 hl=2 l= 12 prim: T61STRING :*.google.com >When I should only get.. > 234:d=5 hl=2 l= 12 prim: T61STRING :*.google.com >Is there a way to suppress [the unwanted part ...] >I'm hoping there's an 'openssl -no_depth_header' or something but >I'm not finding such an option. Before when I did my grep search >if the cert wasn't using the T61STRING then it'd move on to the >next check. However now since it gets this "depth header" back >it thinks it found what I was looking for. When it really never >did find the droid I was looking for. If your actual script "found" this it is different than you showed above. The verify-callback output goes to stderr not stdout, and the pipeline you showed only looks in stdout. Moreover, even if the callback-verify data is being grepped, in this case it doesn't match T61STRING, and it's quite unlikely (though not impossible) that any other cert will have any ASN.1 typename as a part of any subject name attribute. You can eliminate this data by redirecting e.g. 2>/dev/null on Unix. Other OSes are different but other OSes don't typically have awk and grep available. Some notes: echo -n '' | is the same as </dev/null on Unix for echo's that support -n (and crazy otherwise) the complicated awk you used is exactly the same as awk '/BEGIN CERT/,/END CERT/' or sed -n /../,/../p grepping T61STRING is an unreliable way to get either common name (there are generally two in each cert). Common name can be and often is another type, while other DN attributes, and extensions, might be T61STRING. It would be safer to use x509 -noout -subject (and/or -issuer if that's what you want) -nameopt multiline and grep. (awk could search singleline form with RS=/ but would malfunction if there's a data slash.) Subject.CN *.google.com would not actually be valid for HTTPS URLs on google.com . Fortunately, the cert served at google.com:443 has SAN with numerous names including both *.google.com and google.com . According to 5280 it's permitted to leave Subject empty when using SAN, although I haven't seen public CAs doing so (yet?). ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org