So the last few weeks I have spent a reasonable amount of time looking at performance and networking related problems associated with revocation repositories. I still have some additional work to do but I figured I would capture some of my findings in a quick post.
CRL repositories and IPv6
CA | Host | Supports V6 |
GlobalSign | crl.globalsign.com | Yes |
Comodo | crl.comodoca.com | No/Sometimes |
CyberTrust | sureseries-crl.cybertrust.ne.jp | No |
Symantec/GeoTrust | EVSSL-crl.geotrust.com | No |
Symantec/VeriSign | EVIntl-crl.verisign.com | No |
DigiCert | crl3.digicert.com | No |
StartSSL | crl.startssl.com | No |
TrustWave | crl.securetrust.com | No |
TrustCenter | crl.ix.tcclass3.tcuniversal-i.trustcenter.de | No |
GoDaddy | crl.godaddy.com | No |
Entrust | crl.entrust.net | No |
Certum | crl.certum.pl | No |
* IPv6 Capability was checked via http://ipv6-test.com/validate.php
OCSP repositories and IPv6
CA | Host | Supports V6 |
GlobalSign | ocsp.globalsign.com | Yes |
COMODO | ocsp.comodoca.com | No |
GoDaddy | ocsp.godaddy.com | No |
DigiCert | ocsp.digicert.com | No |
StartCom | ocsp.startssl.com | No |
TrustCenter | ocsp.tcuniversal-I.trustcenter.de | No |
TrustWave | ocsp.trustwave.com | No |
Enstrust | ocsp.entrust.net | No |
Symantec/GeoTrust | ocsp.geotrust.com | No |
Symantec/VeriSign | ocsp.verisign.com | No |
CyberTrust | sureseries-ocsp.cybertrust.ne.jp | No |
Certum | ocsp.certum.pl | No |
* IPv6 Capability was checked via http://ipv6-test.com/validate.php
CRL Size
CA | CRL | Size | # Entries |
Certum | http://crl.certum.pl/evca.crl | 862 | 7 |
Symantec/Geotrust | http://EVSSL-crl.geotrust.com/crls/gtextvalca.crl | 720 | 12 |
Cybertrust | http://sureseries-crl.cybertrust.ne.jp/SureServer/2021_ev/cdp.crl | 1742 | 17 |
GlobalSign | http://crl.globalsign.com/gs/gsextendvalg2.crl | 1114 | 18 |
TrustWave | http://crl.securetrust.com/STCA.crl | 2158 | 65 |
StartSSL | http://crl.startssl.com/crt4-crl.crl | 2339 | 90 |
DigiCert | http://crl3.digicert.com/evca1-g1.crl | 5393 | 100 |
GoDaddy | http://crl.godaddy.com/gds3-37.crl | 6848 | 153 |
Comodo | http://crl.comodoca.com/COMODOExtendedValidationSecureServerCA.crl | 12959 | 351 |
TrustCenter | http://crl.ix.tcclass3.tcuniversal-i.trustcenter.de/crl/v2/tc_class3_L1_CA_IX.crl | 16138 | 407 |
Entrust | http://crl.entrust.net/level1e.crl | 40995 | 1005 |
Symantec/VeriSign | http://EVIntl-crl.verisign.com/EVIntl2006.crl | 207922 | 5972 |
* CRL count was determined using “curl url>crl & openssl crl -in crl -inform der -text | grep -c “Serial” | |||
* Size was determined using the Content-Length header, “curl –verbose –url *” |
OCSP response Size
CA | Host | Size |
Comodo | ocsp.comodoca.com | 471 |
Digicert | ocsp.digicert.com | 471 |
GlobalSign | ocsp2.globalsign.com | 1491 |
CyberTrust | sureseries-ocsp.cybertrust.ne.jp | 1588 |
StartSSL | ocsp.startssl.com | 1596 |
Symantec/Verisign | ocsp.verisign.com | 1739 |
GoDaddy | ocsp.godaddy.com | 1923 |
Entrust | ocsp.entrust.net | 1939 |
Certum | ocsp.certum.pl | 2113 |
Trustwave | ocsp.trustwave.com | 2519 |
TrustCenter | ocsp.tcuniversal-I.trustcenter.de | 3135 |
Symantec/Geotrust | ocsp.geotrust.com | 3346 |
* Size was determined using the Content-Length header, “curl –verbose –url *”
OCSP Response Performance
CA | Host | Average (ms) |
GlobalSign | ocsp2.globalsign.com |
95 |
DigiCert | ocsp.digicert.com |
156 |
GoDaddy | ocsp.godaddy.com |
163 |
COMODO | ocsp.comodoca.com |
202 |
StartCom | ocsp.startssl.com |
280 |
Enstrust | ocsp.entrust.net |
293 |
Symantec/GeoTrust | ocsp.geotrust.com |
293 |
Symantec/VeriSign | ocsp.verisign.com |
295 |
TrustWave | ocsp.trustwave.com |
297 |
TrustCenter | ocsp.tcuniversal-I.trustcenter.de |
389 |
CyberTrust | sureseries-ocsp.cybertrust.ne.jp |
421 |
Certum | ocsp.certum.pl |
568 |
* Measuring with Monitis points in US-MID, US-EST-US-WST, Canada, Denmark, Netherlands, Germany, Spain, UK, Sweden, China, Austrailia, Signapore, Japan were used. |
CRL Repository Performance
CA | Host | Average (ms) |
GlobalSign | crl.globalsign.com | 101 |
DigiCert | crl3.digicert.com | 102 |
Entrust | crl.entrust.net | 120 |
Comodo | crl.comodoca.com | 178 |
GoDaddy | crl.godaddy.com | 186 |
StartCom | crl.startssl.com | 267 |
TrustWave | crl.securetrust.com | 272 |
Symantec/GeoTrust | EVSSL-crl.geotrust.com | 298 |
Symantec/Verisign | EVIntl-crl.verisign.com | 298 |
TrustCenter | crl.ix.tcclass3.tcuniversal-i.trustcenter.de | 371 |
Certum | crl.certum.pl | 426 |
CyberTrust | sureseries-crl.cybertrust.ne.jp | 454 |
* Measuring with Monitis points in US-MID, US-EST-US-WST, Canada, Denmark, Netherlands, Germany, Spain, UK, Sweden, China, Austrailia, Signapore, Japan were used. |
Nice job. IPv6 is a bonus.
CRL size is wrong for GlobalSign (1144 instead of 114) and for GoDaddy (remove the trailing ‘a’ in the URL to get the real one).
CRL #entries should really be counted (openssl crl … | grep -c “Serial Number:”), because CRL entry sizes vary a lot. For example GeoTrust uses 2 bytes serial numbers (sequential, which must have been prohibited since 2008 at least), while Certum uses 16bytes ones with a reason code for each entry.
(Why is the “website” entry mandatory for comments?)
I fixed the table, copy and paste errors 🙁
As for the CRL count, I agree its just an apx, no time to fix right now.
As for the website, Its the default I will look into it.
Fixed the CRL counts.
I noticed you mentioned Comodo’s CRL was available via IPv6, however I’m finding the CRLs accessibility over IPv6 very inconsistent. i noticed this when working with a PDF file signed with a client cert issued by Comodo. Several test with curl confirm the same, no failures over IPv4 (20/20) and IPv6 could only do 60% (12/20). The 60% was the best for IPv6 other test runs fared worse. Just for comparison accessing GlobalSign’s CRL over IPv6 was perfect (20/20) over multiple iterations.
Hi,
I was told that GlobalSign was the first one in getting this. But…is there any other one compliant? What about COMODO? Symantec? I found some info about those 2 being compatible.
Any update on this?
Is there a public .org or .com page from a regulatory institution who can confirm this?
Best regards
Yes, we were (I am no longer with them) I have not checked in some time but I know that several others are now using CDNs for distribution so in theory they too should be available over ipv6 even if their networks are still IPv4. Unfortunately you will have to check case by case as the report I used to produce for this needs too much work to check easily sorry.
Pingback: IPv6 Support by Certificate Authorities (CAs) - Infoblox Blog