>From: [email protected] 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 [email protected]
Automated List Manager [email protected]
