Home page logo

nmap-dev logo Nmap Development mailing list archives

[Ncat] ca-bundle.crt contains expired certs
From: Daniel Miller <bonsaiviking () gmail com>
Date: Thu, 19 May 2011 18:49:10 -0500


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
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
/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

Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]