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 126.96.36.199, 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
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 188.8.131.52 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 184.108.40.206.
The DNS answer from the Google name server is shown below:
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 220.127.116.11 Name: ocsp.comodoca.com Type: A (Host Address) (1) Class: IN (0x0001) Time to live: 232 Data length: 4 Address: 18.104.22.168
The ocsp.trust-provider.com FQDN is an alias for
ocsp.comodoca.com, thus the
I removed the Wireshark filter to see the subsequent non-DNS traffic and
saw a a Hypertext Transfer Protocol (HTTP) connection to
22.214.171.124 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)
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
The same IP address was returned, 126.96.36.199.
ocsp.comodoca4.com: Type A, class IN, addr 188.8.131.52 Name: ocsp.comodoca4.com Type: A (Host Address) (1) Class: IN (0x0001) Time to live: 3274 Data length: 4 Address: 184.108.40.206
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:
$ ./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 $
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.
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
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.
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
$ 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
220.127.116.11 that showed references to certificates for the following
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).