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.

Symantec firewall alert - gvim.exe

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:

Wireshark Certification
Wireshark Certification
1x1 px

ocsp.trust-provider.com: type CNAME, class IN, cname ocsp.comodoca.com
   Name: ocsp.trust-provider.com
   Type: CNAME (Canonical NAME for an alias) (5)
   Class: IN (0x0001)
   Time to live: 2143
   Data length: 16
   CNAME: ocsp.comodoca.com
ocsp.comodoca.com: Type A, class IN, addr 178.255.83.1
   Name: ocsp.comodoca.com
   Type: A (Host Address) (1)
   Class: IN (0x0001)
   Time to live: 232
   Data length: 4
   Address: 178.255.83.1

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:

Wireshark - 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)

The timestamps were in Coordinated Universal Time (UTC); UTC, aka GMT and zulu time, is currently 5 hours ahead of the time zone I'm in. The three values have the following meaning according to the RFC:

Responses defined in this document can contain four times --
   thisUpdate, nextUpdate, producedAt, and revocationTime.  The
   semantics of these fields are:

   thisUpdate      The most recent time at which the status being
                   indicated is known by the responder to have been
                   correct.

   nextUpdate      The time at or before which newer information will be
                   available about the status of the certificate.

   producedAt      The time at which the OCSP responder signed this
                   response.

   revocationTime  The time at which the certificate was revoked or
                   placed on hold.

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.

ocsp.comodoca4.com: Type A, class IN, addr 178.255.83.1
   Name: ocsp.comodoca4.com
   Type: A (Host Address) (1)
   Class: IN (0x0001)
   Time to live: 3274
   Data length: 4
   Address: 178.255.83.1

The URI requested was as follows:

[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:

Work More Efficiently With Wireshark
Work More Efficiently
With Wireshark
1x1 px

$ ./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:

Network Analysis Using Wireshark
Network Analysis
Using Wireshark
1x1 px

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

I downloaded the .crt file, which is an X.509 certificate encoded as binary DER or ASCII PEM, from http://crt.comodoca.com/COMODOECCCertificationAuthority.crt to the Windows 7 laptop and then double-clicked on it to open it. The certificate was issued to "COMODO ECC Certification Authority.

COMODO ECC Certification Authority

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.

COMODO Subject Key
Identifier

The thumbprint value, 9F744E9F2B4DBAEC0F312C50B6563B8E2D93C311, matched the SHA1 Fingerprint value, I saw at the Mozilla Foundation's Add COMODO ECC Certification Authority root certificate and enable it for EV page. The Mozilla Foundation supports the development of the Firefox web browser.

COMODO ECC Cert. Authority 
thumbprint

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.

Udemy - April2516-25off-sitewide120x600
$ 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

Wireshark OCSP filter

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).

Related articles:

  1. gVim Portable for Windows
  2. Capturing and filtering data with Wireshark
  3. Symantec OCSP - gn.symcd.com
  4. Verifying an SSL Certificate

References:

  1. The Most Common OpenSSL Commands
    SSLShopper
  2. Add COMODO ECC Certification Authority root certificate and enable it for EV
    Date: March 10, 2008
    Bugzilla