>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

Reply via email to