Comodo OCSP

After I started the gVim text editor on a Windows laptop, I saw a "firewall alert" from the Symantec antivirus/firewall software on the system stating "Suspicious network activity has been detected." I've used gVim on many other systems for many years, but those systems weren't running the Symantec security software. The Symantec software showed that gvim.exe was attempting a Domain Name System (DNS) query to port 53, the well-known port for DNS, to IP address 8.8.8.8, the Google DNS server specified on the system for DNS queries.

Since I was curious as to the details for the DNS query the gVim editor program wanted to submit, I blocked the query until I started the Wireshark packet analyzer program I already had installed on the laptop to capture the network traffic. I then allowed the DNS query and filtered the Wireshark data with a tcp.port == 53 || udp.port == 53 filter to see just the DNS traffic and saw a DNS query to 8.8.8.8 to look up the IP address for ocsp.trust-provider.com, a domain registered to CSC Corporate Domains in Wilmington DE in the U.S. The address returned for the fully qualified domain name (FQDN) was 178.255.83.1. The DNS answer from the Google name server is shown below:

The ocsp.trust-provider.com FQDN is an alias for ocsp.comodoca.com, thus the CNAME reference. I removed the Wireshark filter to see the subsequent non-DNS traffic and saw a a Hypertext Transfer Protocol (HTTP) connection to 178.255.83.1 on port 80. The requested Uniform Resource Identifier (UR) was as follows:

[Full request URI: http://ocsp.trust-provider.com/MFEwTzBNMEswSTAJBgUrDgMCGgUABBR8sWZUnKvbRO5iJhat9GV793rVlAQUrb2YejS0Jvf6xCZU7wO94CTLVBoCEENSAj%2F6qJAfE5%2Fj9OXBRE4%3D]

OCSP stands for "Online Certificate Status Protocol", which is an Internet protocol used to check the validity of security certificates for websites and is described in RFC 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. Wireshark showed the following OCSP response:

When I looked at the details of the OCSP response, I saw "responseStatus: successful (0)" and "certStatus: good (0)". I also saw the following values:

producedAt: 2018-01-11 22:44:51 (UTC)
thisUpdate: 2018-01-11 22:44:51 (UTC)
nextUpdate: 2018-01-18 22:44:51 (UTC)

So the status provided by the OCSP server was last updated about 3 days ago and will next be updated in about 4 more days.

After the HTTP exchange between the laptop and OCSP server, I saw another DNS query from the laptop, but this time for ocsp.comodoca4.com. The same IP address was returned, 178.255.83.1.

[Full request URI: http://ocsp.comodoca4.com/MFEwTzBNMEswSTAJBgUrDgMCGgUABBTrJdiQ%2Ficg9B19asFe73bPYs%2BreAQUdXGnGUgZvJ2d6kFH35TESHeZ03kCEFslzmkHxCZVZtM5DJmpVK0%3D]

The response from the OCSP server seemed similar to the one before with the same producedAt, thisUpdate, and nextUpdate values. I decoded both OCSP queries using the decode-ocsp-get Python script written by Malini Kothapalli and also available for download here. The usage information for the script is shown below:

$ ./decode-ocsp-get.py -h
usage: decode-ocsp-get.py [-h] (-r REQUEST | -i INPUTFILE) [-o OUTPUTFILE]
                          [-e ERRORFILE]

decode get ocsp requests and print in ASN.1 format

optional arguments:
  -h, --help            show this help message and exit
  -r REQUEST, --request REQUEST
                        get ocsp request url
  -i INPUTFILE, --inputfile INPUTFILE
                        file with multiple ocsp request urls
  -o OUTPUTFILE, --outputfile OUTPUTFILE
                        output to this file, default is stdout
  -e ERRORFILE, --errorfile ERRORFILE
                        write errors to this file, by default errors are
                        written to stderr
$

When I used the -r option to query the two URLs I had seen in the Wireshark data capture, I saw the following:

$ ./decode-ocsp-get.py -r http://ocsp.comodoca4.com/MFEwTzBNMEswSTAJBgUrDgMCGgUA
BBTrJdiQ%2Ficg9B19asFe73bPYs%2BreAQUdXGnGUgZvJ2d6kFH35TESHeZ03kCEFslzmkHxCZVZtM5DJmpVK0%3D
OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: EB25D890FE2720F41D7D6AC15EEF76CF62CFAB78
          Issuer Key Hash: 7571A7194819BC9D9DEA4147DF94C4487799D379
          Serial Number: 5B25CE6907C4265566D3390C99A954AD
$ ./decode-ocsp-get.py -r http://ocsp.trust-provider.com/MFEwTzBNMEswSTAJBgUrDgM
CGgUABBR8sWZUnKvbRO5iJhat9GV793rVlAQUrb2YejS0Jvf6xCZU7wO94CTLVBoCEENSAj%2F6qJAfE5%2Fj9OXBRE4%3D
OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: 7CB166549CABDB44EE622616ADF4657BF77AD594
          Issuer Key Hash: ADBD987A34B426F7FAC42654EF03BDE024CB541A
          Serial Number: 4352023FFAA8901F139FE3F4E5C1444E
$

When I clicked on the Details tab and looked at the "Subject Key Identifier" field, I saw it matched the Issuer Key Hash for the result from

./decode-ocsp-get.py -r 
	http://ocsp.comodoca4.com/MFEwTzBNMEswSTAJBgUrDgMCGgUA

I uploaded the COMODOECCCertificationAuthority.crt file to a Linux system and then converted the .crt file to a .pem file using the openssl utility. You can convert Convert a DER file (.crt .cer .der) to PEM using a command in the form

openssl x509 -inform der -in certificate.cer -out 
certificate.pem

$ openssl x509 -inform der -in COMODOECCCertificationAuthority.crt -out COMODOEC
CCertificationAuthority.pem
$ file COMODOECCCertificationAuthority.*
COMODOECCCertificationAuthority.crt: data
COMODOECCCertificationAuthority.pem: PEM certificate
$ openssl x509 -text -noout -in COMODOECCCertificationAuthority.pem
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            1f:47:af:aa:62:00:70:50:54:4c:01:9e:9b:63:99:2a
    Signature Algorithm: ecdsa-with-SHA384
	Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=
COMODO ECC Certification Authority
        Validity
            Not Before: Mar  6 00:00:00 2008 GMT
            Not After : Jan 18 23:59:59 2038 GMT
	Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN
=COMODO ECC Certification Authority
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                pub:
                    04:03:47:7b:2f:75:c9:82:15:85:fb:75:e4:91:16:
                    d4:ab:62:99:f5:3e:52:0b:06:ce:41:00:7f:97:e1:
                    0a:24:3c:1d:01:04:ee:3d:d2:8d:09:97:0c:e0:75:
                    e4:fa:fb:77:8a:2a:f5:03:60:4b:36:8b:16:23:16:
                    ad:09:71:f4:4a:f4:28:50:b4:fe:88:1c:6e:3f:6c:
                    2f:2f:09:59:5b:a5:5b:0b:33:99:e2:c3:3d:89:f9:
                    6a:2c:ef:b2:d3:06:e9
                ASN1 OID: secp384r1
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                75:71:A7:19:48:19:BC:9D:9D:EA:41:47:DF:94:C4:48:77:99:D3:79
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
    Signature Algorithm: ecdsa-with-SHA384
         30:65:02:31:00:ef:03:5b:7a:ac:b7:78:0a:72:b7:88:df:ff:
         b5:46:14:09:0a:fa:a0:e6:7d:08:c6:1a:87:bd:18:a8:73:bd:
         26:ca:60:0c:9d:ce:99:9f:cf:5c:0f:30:e1:be:14:31:ea:02:
         30:14:f4:93:3c:49:a7:33:7a:90:46:47:b3:63:7d:13:9b:4e:
         b7:6f:18:37:80:53:fe:dd:20:e0:35:9a:36:d1:c7:01:b9:e6:
         dc:dd:f3:ff:1d:2c:3a:16:57:d9:92:39:d6
$

You can filter on just OCSP traffic in Wireshark using a filter of ocsp. When I applied that filter, I found that there was a prior OCSP packet before the ones I had been examining going to IP address 104.25.219.21 that showed references to certificates for the following systems:

ssl380445.cloudflaressl.com
COMODO ECC Domain Validation Secure Server CA
COMODO ECC Certification Authyority

In that first OCSP packet, I saw references to the serial numbers for the three certificates. E.g. 0x4352023ffaa8901f139fe3f4e5c1444e - the 0x at the beginning of the string indicates that the value is a hexadecimal number and 0x5b25ce6907c4265566d3390c99a954ad. A client system, e.g., the laptop will send OCSP queries to an OCSP server, aka responder, with the serial number of a X.509 security certificate for a website to be checked. The responder should then send a response indicating the status of the certificate is "good", "revoked", or "unknown". If it cannot process the request, it may return an error code. For both of the Comodo certificates, Wireshark showed that the next OCSP packets were responses indicating that the certificates were good. Comodo is a U.S. based cybersecurity company. It is a Certificate Authority (CA) that sells digital certificates, which can be used for Secure Sockets Layer (SSL)/Transpport Layer Security (TLS).