[Ncat] ca-bundle.crt contains expired certs

[Daniel Miller <bonsaiviking () gmail com>]

FYI,

The ca-bundle.crt file that Ncat uses for --ssl-verify is out of date. I
started by looking to see if any Comodo certificates were in it (remember
that fiasco?), but decided to do a verification of the others, as best as I
could. I'm sure this is incomplete, since I didn't check for revoked
certificates (I don't think). Here's my process:

# Split the file into separate certificates, each new file named xxNN where
NN is sequential.
csplit ca-bundle.crt '/^$/' '{*}'
# Loop over the certs and verify
for i in xx*; do openssl verify $i; done >verification.txt
# Look for expired certs
grep -B1 expired verification.txt | grep ^/

Here were my results:

/C=US/ST=Utah/L=Salt Lake City/O=Xcert EZ by DST/CN=Xcert EZ by
> DST/emailAddress=ca () digsigtrust com
> /L=Internet/O=VeriSign, Inc./OU=VeriSign Individual Software Publishers CA
> /L=Internet/O=VeriSign, Inc./OU=VeriSign Individual Software Publishers CA
> /C=hk/O=C&W HKT SecureNet CA Class B
> /C=hk/O=C&W HKT SecureNet CA Class A
> /C=be/O=Belgacom/OU=MTM/CN=Belgacom E-Trust Primary CA/mail=
> info () e-trust be
> /C=US/O=Digital Signature Trust Co./CN=Baltimore EZ by DST/mail=
> ca () digsigtrust com
> /C=MX/CN=Autoridad Certificadora del Colegio Nacional de Correduria Publica
> Mexicana, A.C./O=Colegio Nacional de Correduria Publica Mexicana, A.C.
> /C=MX/CN=Autoridad Certificadora de la Asociacion Nacional del Notariado
> Mexicano, A.C./O=Asociacion Nacional del Notariado Mexicano, A.C.
> /L=Internet/O=VeriSign, Inc./OU=VeriSign Commercial Software Publishers CA
> /L=Internet/O=VeriSign, Inc./OU=VeriSign Commercial Software Publishers CA
> /C=DE/ST=Hamburg/L=Hamburg/O=TC TrustCenter for Security in Data Networks
> GmbH/OU=TC TrustCenter Time Stamping CA/CN=TC TrustCenter Time Stamping CA
> /C=DE/ST=Hamburg/L=Hamburg/O=TC TrustCenter for Security in Data Networks
> GmbH/OU=TC TrustCenter Class 4 CA/emailAddress=certificate () trustcenter de
> /C=DE/ST=Hamburg/L=Hamburg/O=TC TrustCenter for Security in Data Networks
> GmbH/OU=TC TrustCenter Class 1 CA/emailAddress=certificate () trustcenter de
> /C=UY/O=ADMINISTRACION NACIONAL DE CORREOS/OU=SERVICIOS
> ELECTRONICOS/CN=SERVICIOS DE CERTIFICACION - A.N.C./mail=
> correo_cert () correo com uy
> /C=au/O=SecureNet CA SGC Root
> /C=au/O=SecureNet CA Root
> /C=au/O=SecureNet CA Class B
> /C=au/O=SecureNet CA Class A
> /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign Time Stamping
> Service Root/OU=NO LIABILITY ACCEPTED, (c)97 VeriSign, Inc.
> /C=US/O=MSFT/CN=Microsoft Authenticode(tm) Root Authority
> /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust
> Root
> /C=us/ST=Utah/L=Salt Lake City/O=Digital Signature Trust Co./OU=United
> Parcel Service/CN=DST (UPS) RootCA/emailAddress=ca () digsigtrust com
> /C=us/ST=Utah/L=Salt Lake City/O=Digital Signature Trust Co./OU=National
> Retail Federation/CN=DST (NRF) RootCA/emailAddress=ca () digsigtrust com
> /O=Microsoft Trust Network/OU=Microsoft Corporation/OU=Microsoft Time
> Stamping Service Root/OU=Copyright (c) 1997 Microsoft Corp.
> /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
> /C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority
> /C=hk/O=C&W HKT SecureNet CA SGC Root
> /C=hk/O=C&W HKT SecureNet CA Root

By my count, 29 of the 106 certificates are expired. The problem of whom to
trust in certificate verification is complex, but in the case of Ncat, there
are likely fewer security holes than in the average Web browser, so we can
be a little more lenient. It comes down to the use cases: why do Ncat users
use the --ssl-verify feature? I can't really answer that, since I don't use
it myself. But I think we would best serve the Ncat users by at least
updating the file from the Microsoft source that's mentioned in
ncat/certs/README.

Dan
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/