Re: Expired Root CA in certdata.txt

The way I understand it is, generally speaking, Root CAs may be kept in a root store for as long as the root key material is not compromised in any way. In practice Root CA certificates are removed at the operator's request when they believe it is no longer needed, or the root store operator

Re: Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3

Visiting the www.emsign.com homepage brings up a list of proposed products. Currently, in the "Types of Certificate" table halfway down the page is the following: Wildcard SSL - OV Wildcard SSL - EV UCC Wildcard SSL - DV UCC Wildcard SSL - OV UCC Wildcard SSL - EV That's not a good sign at

CAs not compliant with CAA CP/CPS requirement

Is there a typo here? Digicert.net.jp and Cybertrust.net.jp do not resolve, Japan tends to use the .NE.jp suffix, not .net.jp . Therefore shouldn't these be Digicert.ne.jp and Cybertrust.ne.jp ? These two do indeed resolve. On this subject, I am curious as to why it appears a lot of CA's do not

Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

There's more than just a clue in the name drmlocal.cisco.com , if one looks up this address in the DNS it returns the loopback IP 127.0.0.1 . http://dnstools.ws/tools/lookup.php?host=drmlocal.cisco.com=A This can only mean that this address is fully intended to be referred to only by one's own

Re: CloudFlare Issuing SHA-1 SSL Certificates

It looks like "CloudFlare Inc Compatibility CA-3" chains back to the "GTE CyberTrust Global Root" (see https://crt.sh/?caid=34007 ) The "GTE CyberTrust Global Root" is an old 1024 bit root that was removed from NSS two years ago (see https://bugzilla.mozilla.org/show_bug.cgi?id=1047011 ), and