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, 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 to look up the IP address for, 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 The DNS answer from the Google name server is shown below:

Wireshark Certification
Wireshark Certification
1x1 px type CNAME, class IN, cname
   Type: CNAME (Canonical NAME for an alias) (5)
   Class: IN (0x0001)
   Time to live: 2143
   Data length: 16
   CNAME: Type A, class IN, addr
   Type: A (Host Address) (1)
   Class: IN (0x0001)
   Time to live: 232
   Data length: 4

The FQDN is an alias for, 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 on port 80. The requested Uniform Resource Identifier (UR) was as follows:

[Full request URI:]

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

   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

   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 The same IP address was returned, Type A, class IN, addr
   Type: A (Host Address) (1)
   Class: IN (0x0001)
   Time to live: 3274
   Data length: 4

The URI requested was as follows:

[Full request URI:]

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

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

$ ./ -r
OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: EB25D890FE2720F41D7D6AC15EEF76CF62CFAB78
          Issuer Key Hash: 7571A7194819BC9D9DEA4147DF94C4487799D379
          Serial Number: 5B25CE6907C4265566D3390C99A954AD
$ ./ -r
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 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 ./ -r

COMODO Subject Key

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 

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 Generic Category (English)120x600
$ openssl x509 -inform der -in COMODOECCCertificationAuthority.crt -out COMODOEC
$ file COMODOECCCertificationAuthority.*
COMODOECCCertificationAuthority.crt: data
COMODOECCCertificationAuthority.pem: PEM certificate
$ openssl x509 -text -noout -in COMODOECCCertificationAuthority.pem
        Version: 3 (0x2)
        Serial Number:
    Signature Algorithm: ecdsa-with-SHA384
	Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=
COMODO ECC Certification Authority
            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)
                ASN1 OID: secp384r1
        X509v3 extensions:
            X509v3 Subject Key Identifier:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
    Signature Algorithm: ecdsa-with-SHA384

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 that showed references to certificates for the following systems:
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 -
  4. Verifying an SSL Certificate


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