Skip to main content Logo (IEC resistor symbol)logo

Quis custodiet ipsos custodes?
Home | About | All pages | RSS Feed | Gopher

How I got a valid SSL certificate for my ISP's main domain,

Published: 21-03-2015 | Author: Remy van Elst | Text only version of this article

Table of Contents


Click the image to see the certificate.

What happened

I got a valid SSL certificate for a domain that is not mine by creating an emailalias. In this article I'll explain what happened, why that was possible and howwe all can prevent this.

My ISP, xs4all, allows me to create personal mailboxes and email aliases.

An SSL domain validation certificate requires you to click on a link sent to apre-specified set of email addresses. I was able to register one of those emailaddresses ( With that email address, I was able toreceive a validation link for a certificate.

The certificate provider Comodo thus issues me a certificate for the, because I was able to "provide ownership".

This should not be possible, the provider should have a blacklist for thoseaddresses.

With this certificate I would be able to do a Man in the Middle attack againstusers, provided I can intercept their connections, for example, at a coffee shopor other place free Wifi is provided. The users would not receive a warning whenthey would connect to over my, snooped, connection because it is avalid certificate trusted by all major browsers and operating systems.

With the email address I could also request more certificates, for example, or their service portal.

I directly contacted xs4all and the dutch National Cyber Security Center toinform them and other ISP's. The certificate was also revoked a few minutesafter issueing.

xs4all have blocked the administrator@ email address from the aliasses list,so this should not be possible in the future.


How does SSL validation work

When you request an SSL certificate for a domain you need to proof that you arethe owner of that domain. There are multiple ways to do that, as there aremultiple types of certificates. These types of certificates are technically thesame, the validation behind it is what is different.

The CA/Browser forum, the standards body for Certificate Authorities has setbaseline requirements which describe exactly how these validations shouldoccur. The certificate provider, Comodo in this case, was not at fault here.They have followed the procedure, the ISP was at fault because they allowed thatemail alias.

Domain Validation certificates

A domain validation, or DV certificate is the simplest form of validationpossible. The CA checks the right of the applicant to use a specific domainname. No company identity information is vetted.

Chapter 3.2.2 (Authentication of Organization and Domain Identity", respectively" Authorization by Domain Name Registrant") of the CABrequirements states the following for this verification:

If the CA uses the Internet mail system to confirm that the Applicant hasauthorization from the Domain Name Registrant to obtain a Certificate for therequested Fully-Qualified Domain Name, the CA SHALL use a mail system addressformed in one of the following ways:

  1. Supplied by the Domain Name Registrar;
  2. Taken from the Domain Name Registrant's "registrant", "technical", or "administrative" contactinformation, as it appears in the Domain's WHOIS record; or;
  3. By pre-pending a local part to a Domain Name as follows: a. Local part - One of the following: 'admin', 'administrator', 'webmaster', 'hostmaster', or 'postmaster'; and b. Domain Name - Formed by pruning zero or more components from the Registered Domain Name or the requested Fully-Qualified Domain Name.

So, if you are able to receive an email on one of those addresses you canprovide domain ownership to the certificate provider.

Organization Validation

This is one level up from the DV certificate, the Organization Validation, or OVcertificate. The CA checks the right of the applicant to use a specific domainname PLUS it conducts some vetting of the organization. This means that theWHOIS company information is compared to the local country's business registry.For example, in The Netherlands that is the Kamer van Koophandel and inthe UK that is the Companies House.

The same email verification is done as with a DV certificate, plus yourcompany's WHOIS address and company number is compared to data in such aregistry.

The false certificate would not have been issues if I have tried to get the OVvariant of this certificate. If I would have given the correct company datainstead of my personal data during the application it would have been.

Extended validation

An Extended Validation, or EV certificate is a certificate where the browserdisplays a green bar with the company name. This certificate has the highestlevel of validation behind it.

All the checks for a DV and an OV certificate are performed. The company data ischecked in a local registry. Then the CA calls up the phone number in thecompany registry, and gives you a special code. The email you received earliercontains a link where you need to enter the code, and if that is all correct thecertificate will be issues.

This extra step of calling the applicant is the only extra check they do, andeven that is automated. If you have a PBX or a call-menu you're out of luckbecause their calling system fails then. Good luck manually contacting them andgetting the number changed...

How can we prevent this

There are a lot of certificate authorities, and by a lot I mean hundreds. Theyare all trusted by your browser, and all can issue certificates for any givendomain.

This ranges from large companies like Comodo, Thawte or Verisign, but alsocountries. For example, The Netherlands have a ceritifcate tree (Staat derNederlanden Root CA) which is trusted by all major platforms. China, viathe Hong Kong Post Office as well.

Any CA can issue a certificate for ANY domain. That is a problem as well as abenefit. A benefit because it allows you to choose the CA. It also allows you tohave multiple certificates, a backup certificate from another CA for example.

It is a problem because, if unnoticed, the Hong Kong Post office can issuecertificates for American companies and with those intercept people'scommunication when they are in China, without them noticing.

We've had issues with this system, Diginotar was hacked, Turktrust has issuedwrong certificates, TrustWave issued a CA (subordinate) certificate to one ofit's customers instead of a regular certificate, Malasyan DigiCert Sdn. Bhdissues weak certificates and even Microsofts domain was not safe.

There are a few ways to mitigate this problem. Certificate Transparency, PublicKey Pinning (HPKP) and DNS based authentication of Named Entities (DANE).

A combination of these solutions would have prevented this from happening.xs4all did set up at least one of these things (TLSA), if all browsers wouldsupport this then my certificate would be unusable. I'll cover a few of thesemeasurements here below.

Certificate Transparency


The Certificate Transparency project aims to remedy these certificate-based threats by making the issuance and existence of SSL certificates open toscrutiny by domain owners, CAs, and domain users. Specifically, CertificateTransparency has three main goals:

  1. Make it impossible (or at least very difficult) for a CA to issue a SSL certificate for a domain without the certificate being visible to the owner of that domain.
  2. Provide an open auditing and monitoring system that lets any domain owner or CA determine whether certificates have been mistakenly or maliciously issued.
  3. Protect users (as much as possible) from being duped by certificates that were mistakenly or maliciously issued.

They do this with Certificate Logs, Auditors and Monitors. It would providefaster detection of mis-issued certificates and rouge CA's, plus fastermitigation of issues like these. It is a very interesting project, read thewebsite to find out more about it. It does requires adoption by the CA's.

HTTP Public Key Pinning (HPKP)

HTTP Public Key Pinning means that a certificate chain must include awhitelisted public key. It ensures only whitelisted Certificate Authorities (CA)can sign certificates for *, and not any CA in your browser store.

HPKP allows a website owner to specify public keys in the website headers. Thesepublic keys must be in the certificate chain, otherwise the validation willfail.

It allows you to include the public key of your certificate and a backupcertificate. Browsers save these headers, if you've visited a website (withHPKP) once and later on the certificate is changed maliciously, your browserwill fail to connect to the website.

An example might be your bank, which always have their certificate from CACompany A. With the current certificate system, CA Company B, CA Company C andthe NSA CA can all create a certificate for your bank, which your browser willhapily accept because those companies are also trusted root CA's.

If the bank implements HPKP and pin's their first intermidiate certificate (fromCA Company A), browsers will not accept certificates from CA Company B and CACompany C, even if they have a valid trust path. HPKP also allows your browserto report back the failure to the bank, so that they know they are under attack.

I've written an article about HPKP which explains this in more detail andprovides configuration examples for Apache, NGINX and Lighttpd.

DNS based authentication of Named Entities (DANE)

DANE enables the administrator of a [domain name to certify the keys usedin that domain's TLS clients or servers by [storing them in the Domain NameSystem (DNS). DANE needs DNS records to be [signed with DNSSEC.

The difference with HTTP Public Key Pinning is that this data is in a DNSrecord, not in the HTTP headers. For HPKP to work you need to have visited thewebsite at least once, DANE does not have this requirement because a DNS lookuphappens before the HTTP connection.

None of the major browsers sadly support DANE validation. There is a browserextension available which does support this.

My ISP, xs4all, does have DANE record set up. If all the major browserssupported this, my attempt to set up an MITM attack would fail and thecertificate would be worthless.

This is the TLSA record for, port 443:

$ dig +dnssec +noall +answer +multi 21599 IN TLSA 1 0 1 (                                223A6659D06E9A81390938659E9EF241579E82B820D6                                AFD8E17D548AEDEA3F13 )

If we take the current, valid, public key for we can validatethis.

First convert the PEM file (xs4all.pem) to DER.

openssl x509 -inform PEM -in xs4all.pem -outform DER -out xs4all.der

Then we calculate the SHA 256 hash of this DER file:

openssl sha256 xs4all.der SHA256(xs4all.der)= 223a6659d06e9a81390938659e9ef241579e82b820d6afd8e17d548aedea3f13

This is the same as the TLSA record above. If we take (valid) the certificate Igot it gives us a different SHA 256 hash:

$ openssl x509 -inform PEM -in -outform DER | openssl sha256                                                                    (stdin)= 83618f932d6947744d5ecca299d4b2820c01483947bd16be814e683f7436be24  

That would not be valid according to the TLSA record.

DANE allows a website owner to set up a special TLSA DNS Record. This DNSrecord holds what is called Certificate Association data. In conjunction withDNSSEC signatures, this will permit better and more secure ways for applicationsto authenticate certificates. The record can be used in 4 different ways(defined by a "Usage" field):

If you're looking for a way to not use public CAs, Usage 3 is probably the onefor you. That allows you to just create a self signed certificate and put thehash in a TLSA record, not requiring a certificate from a trusted certificateauthority.

This webpage has a generator if you want to set up your own certificateTLSA record.


A few screenshots and a nice article don't make a whole. Here is the textualoutput of the certificate:

$ openssl x509 -noout -text -in Certificate:    Data:        Version: 3 (0x2)        Serial Number:            52:84:46:9d:bf:7a:09:40:d3:c4:8a:95:af:2e:8b:06    Signature Algorithm: sha256WithRSAEncryption        Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Domain Validation Secure Server CA        Validity            Not Before: Mar 20 00:00:00 2015 GMT            Not After : Mar 19 23:59:59 2016 GMT        Subject: OU=Domain Control Validated, OU=PositiveSSL,        Subject Public Key Info:            Public Key Algorithm: rsaEncryption                Public-Key: (4096 bit)                Modulus:                    00:e3:d4:a4:89:c0:58:6c:ef:f0:0b:b3:97:03:c5:                    f2:37:b3:b4:8c:59:2d:9c:50:04:37:04:2f:b0:31:                    df:a1:e7:fa:6d:78:25:3d:1a:e1:0c:48:7d:4e:af:                    3b:ff:57:d7:e5:19:85:fe:7d:f8:fe:90:33:a0:b0:                    4b:8e:1b:a9:86:4b:6a:70:70:f7:b4:22:de:90:62:                    99:8f:ba:42:8c:20:63:74:16:5d:29:23:4f:08:e1:                    e2:0f:73:17:0f:f4:23:f3:86:6b:4c:24:0a:c1:28:                    9d:cf:82:73:9f:50:59:12:cc:15:60:bb:57:64:71:                    13:6f:b3:04:38:33:59:d3:9f:67:ce:07:0e:85:22:                    a2:19:53:51:1b:76:3c:40:c9:4b:a2:0c:14:05:10:                    6f:f2:b3:6e:6c:b6:95:a6:60:17:d1:2f:bc:b7:19:                    b0:5a:19:b2:98:a4:e9:10:b6:6e:64:68:f4:42:9d:                    e3:b2:7a:17:e9:4b:cd:99:8d:ab:01:58:8f:69:ba:                    a2:2e:e2:54:06:99:a8:72:14:71:a5:f3:25:9b:81:                    92:7a:0c:67:9b:73:5c:11:a8:69:96:1b:99:65:5f:                    64:96:41:f4:91:75:b7:26:cf:a8:2b:a0:28:dc:33:                    90:20:7a:7e:97:72:e0:7c:93:e9:22:a3:b8:28:84:                    58:08:fa:3b:17:08:e8:c4:ce:67:d4:50:23:5c:0e:                    7e:9d:0c:3f:f1:8c:41:53:83:7c:6e:b2:c4:7d:c5:                    fb:68:cb:a5:06:9c:91:8d:3c:9d:2e:20:96:3b:c4:                    b1:fa:ed:58:c2:37:fe:1e:a8:8a:c9:ea:a3:49:5d:                    8d:60:be:88:68:27:2a:cc:6e:e3:ef:55:23:85:7a:                    fc:ad:ed:2f:0e:31:03:c7:10:ba:dd:12:9a:88:5d:                    ef:58:2e:54:e7:78:6a:58:68:3b:e3:78:bc:0f:88:                    3e:b3:3c:2e:05:9e:54:6c:a1:db:e2:9b:01:be:e6:                    92:9d:a7:22:4d:49:17:e1:78:ba:ca:6a:fe:9e:ff:                    d2:80:80:af:7b:a0:10:17:2a:57:f1:31:e4:f0:38:                    88:4b:0c:62:08:18:c5:8a:2a:18:ac:0c:b5:d2:b3:                    4a:e2:d4:de:5c:ba:77:d4:5e:99:a1:19:ab:0b:e7:                    82:a6:69:eb:eb:e2:99:20:9b:bc:84:6a:f4:bc:b0:                    87:78:9c:b2:12:0f:36:57:fa:73:ec:e2:64:90:5b:                    6a:c8:32:69:3b:b6:4e:f8:7d:c5:36:08:13:8b:b0:                    60:0f:90:07:99:c4:a0:fe:a2:b9:d2:e3:30:6b:4d:                    9c:ed:7e:2e:a2:d7:c4:52:01:0e:dd:69:87:12:22:                    8d:f0:87                Exponent: 65537 (0x10001)        X509v3 extensions:            X509v3 Authority Key Identifier:                 keyid:90:AF:6A:3A:94:5A:0B:D8:90:EA:12:56:73:DF:43:B4:3A:28:DA:E7            X509v3 Subject Key Identifier:                 2A:53:FE:18:5C:23:C9:91:A4:71:6A:69:FE:B0:DB:6F:79:2B:43:D8            X509v3 Key Usage: critical                Digital Signature, Key Encipherment            X509v3 Basic Constraints: critical                CA:FALSE            X509v3 Extended Key Usage:                 TLS Web Server Authentication, TLS Web Client Authentication            X509v3 Certificate Policies:                 Policy:                  CPS:                Policy:            X509v3 CRL Distribution Points:                 Full Name:                  URI:            Authority Information Access:                 CA Issuers - URI:                OCSP - URI:            X509v3 Subject Alternative Name:       ,    Signature Algorithm: sha256WithRSAEncryption         33:d6:51:87:3c:b5:7f:29:a7:58:49:54:45:73:c8:de:ab:41:         cd:6c:13:6d:c4:e7:c8:b4:85:dd:b2:6d:91:34:7b:75:d9:71:         16:8a:e7:79:1a:b2:16:7f:ae:d5:2a:61:1d:6c:be:0b:10:af:         1b:cf:a7:b6:7e:51:7c:49:20:07:da:2b:aa:2c:72:1b:70:ab:         6a:ca:ad:8e:ba:7b:98:fa:5e:12:40:b4:cb:8f:dd:35:16:3b:         8b:b4:14:59:56:8c:32:bc:5b:34:36:d4:fc:3a:d6:87:73:70:         ef:e5:fe:43:cf:55:3d:53:d8:ec:2b:ca:06:1b:72:8d:6a:c2:         5f:4c:46:a6:b4:12:1a:0b:ff:f8:40:a1:21:63:31:a6:40:c6:         9d:c3:67:c6:3f:28:6e:16:b6:39:ca:84:64:0d:b7:f3:dc:2f:         76:ca:5a:63:0c:23:2b:5a:d2:7d:13:d5:77:8d:24:38:fe:ac:         73:96:5e:fa:91:df:36:6e:be:4e:9c:52:c6:92:f3:f4:a6:fe:         45:47:3b:e4:52:6d:df:09:76:58:50:29:0f:b9:00:80:bf:37:         30:6e:32:b0:80:d6:97:ba:28:77:70:f0:2f:a0:66:ff:93:a8:         74:89:b4:5d:39:57:3e:da:28:4e:06:48:a1:6c:81:fd:e1:f0:         5a:cb:54:5d

Here is the public key in PEM:

# cat CERTIFICATE-----MIIGPzCCBSegAwIBAgIQUoRGnb96CUDTxIqVry6LBjANBgkqhkiG9w0BAQsFADCBkDELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxNjA0BgNVBAMTLUNPTU9ETyBSU0EgRG9tYWluIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBDQTAeFw0xNTAzMjAwMDAwMDBaFw0xNjAzMTkyMzU5NTlaME0xITAfBgNVBAsTGERvbWFpbiBDb250cm9sIFZhbGlkYXRlZDEUMBIGA1UECxMLUG9zaXRpdmVTU0wxEjAQBgNVBAMTCXhzNGFsbC5ubDCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOPUpInAWGzv8AuzlwPF8jeztIxZLZxQBDcEL7Ax36Hn+m14JT0a4QxIfU6vO/9X1+UZhf59+P6QM6CwS44bqYZLanBw97Qi3pBimY+6QowgY3QWXSkjTwjh4g9zFw/0I/OGa0wkCsEonc+Cc59QWRLMFWC7V2RxE2+zBDgzWdOfZ84HDoUiohlTURt2PEDJS6IMFAUQb/Kzbmy2laZgF9EvvLcZsFoZspik6RC2bmRo9EKd47J6F+lLzZmNqwFYj2m6oi7iVAaZqHIUcaXzJZuBknoMZ5tzXBGoaZYbmWVfZJZB9JF1tybPqCugKNwzkCB6fpdy4HyT6SKjuCiEWAj6OxcI6MTOZ9RQI1wOfp0MP/GMQVODfG6yxH3F+2jLpQackY08nS4gljvEsfrtWMI3/h6oisnqo0ldjWC+iGgnKsxu4+9VI4V6/K3tLw4xA8cQut0Smohd71guVOd4alhoO+N4vA+IPrM8LgWeVGyh2+KbAb7mkp2nIk1JF+F4uspq/p7/0oCAr3ugEBcqV/Ex5PA4iEsMYggYxYoqGKwMtdKzSuLU3ly6d9RemaEZqwvngqZp6+vimSCbvIRq9Lywh3icshIPNlf6c+ziZJBbasgyaTu2Tvh9xTYIE4uwYA+QB5nEoP6iudLjMGtNnO1+LqLXxFIBDt1phxIijfCHAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBSQr2o6lFoL2JDqElZz30O0Oija5zAdBgNVHQ4EFgQUKlP+GFwjyZGkcWpp/rDbb3krQ9gwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCME8GA1UdIARIMEYwOgYLKwYBBAGyMQECAgcwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLmNvbS9DUFMwCAYGZ4EMAQIBMFQGA1UdHwRNMEswSaBHoEWGQ2h0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQURvbWFpblZhbGlkYXRpb25TZWN1cmVTZXJ2ZXJDQS5jcmwwgYUGCCsGAQUFBwEBBHkwdzBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCMGA1UdEQQcMBqCCXhzNGFsbC5ubIINd3d3LnhzNGFsbC5ubDANBgkqhkiG9w0BAQsFAAOCAQEAM9ZRhzy1fymnWElURXPI3qtBzWwTbcTnyLSF3bJtkTR7ddlxForneRqyFn+u1SphHWy+CxCvG8+ntn5RfEkgB9orqixyG3Crasqtjrp7mPpeEkC0y4/dNRY7i7QUWVaMMrxbNDbU/DrWh3Nw7+X+Q89VPVPY7CvKBhtyjWrCX0xGprQSGgv/+EChIWMxpkDGncNnxj8obha2OcqEZA2389wvdspaYwwjK1rSfRPVd40kOP6sc5Ze+pHfNm6+TpxSxpLz9Kb+RUc75FJt3wl2WFApD7kAgL83MG4ysIDWl7ood3DwL6Bm/5OodIm0XTlXPtooTgZIoWyB/eHwWstUXQ==-----END CERTIFICATE-----

Here is the private key:

# cat -----BEGIN PRIVATE KEY-----MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQDj1KSJwFhs7/ALs5cDxfI3s7SMWS2cUAQ3BC+wMd+h5/pteCU9GuEMSH1Orzv/V9flGYX+ffj+kDOgsEuOG6mGS2pwcPe0It6QYpmPukKMIGN0Fl0pI08I4eIPcxcP9CPzhmtMJArBKJ3PgnOfUFkSzBVgu1dkcRNvswQ4M1nTn2fOBw6FIqIZU1EbdjxAyUuiDBQFEG/ys25stpWmYBfRL7y3GbBaGbKYpOkQtm5kaPRCneOyehfpS82ZjasBWI9puqIu4lQGmahyFHGl8yWbgZJ6DGebc1wRqGmWG5llX2SWQfSRdbcmz6groCjcM5Agen6XcuB8k+kio7gohFgI+jsXCOjEzmfUUCNcDn6dDD/xjEFTg3xussR9xftoy6UGnJGNPJ0uIJY7xLH67VjCN/4eqIrJ6qNJXY1gvohoJyrMbuPvVSOFevyt7S8OMQPHELrdEpqIXe9YLlTneGpYaDvjeLwPiD6zPC4FnlRsodvimwG+5pKdpyJNSRfheLrKav6e/9KAgK97oBAXKlfxMeTwOIhLDGIIGMWKKhisDLXSs0ri1N5cunfUXpmhGasL54Kmaevr4pkgm7yEavS8sId4nLISDzZX+nPs4mSQW2rIMmk7tk74fcU2CBOLsGAPkAeZxKD+ornS4zBrTZztfi6i18RSAQ7daYcSIo3whwIDAQABAoICAQDba9qjyJnhIRyhSG9y9NuZBfwnB2REHVRR4DhFi2MEPbUUZRgIR7Di8ZWtiFtSSrnlLbW9Knn6QctXQTMjRET6z/tNG5+U39hWWn/mys54wmDGVxuWGSlvNo1Pr9pQRSOy0IzaIgQxj/qc9diBYRLIZcFZDlTWqYi8lT7FGb+zbty8slMrqfVQSsvclPzmsHelM9i8H96RcnoxPY/XUsjdcQphld4giItXM8w7ile7YNGOrx2ysKAC0jzLXIOLok1M2LCGUvf1+1sds87YstpPcHUwEm5earYLU5WNOjt8RGlNxWvUA/lG6cvfaDqyCP8QKKlvFvZZROLNt7wPWZamDV5a4o7RnVXflLQ7/asQwhIKq38T43q2MwhSA7uCcXTWAxcrJAXVyZ5viAh4tCczwiydGzzFR52jmYrvYuGjmFxO0YiPHy4+XqwXDQEjIR2eaUq46lTM0F6MCp/pWpITYgd0cHcJYNCbUB6ondkw4nB8ZWB3Tuc+jlXc8c3Jkic8P4UaxtsCjHJ8eLt+7/TY/rD9N0dbfmRF0Aq5Dbv4lxAfdz3yt+OcYJ5yQ26MlHPjyds/sv1I0HU8vPY+9xaAS07xU0rF2Iv+BF3LSv4MbMICGmKtsBAZseAxCSmPQ5nbU7R64xADgq59CfgLTx2kKAMBuNMo1nbbgWgAstnGcQKCAQEA+TcqTL/YwTUdCiaLt8xKK+KWyACsdGDXcSVKGUMvV4/3EnGjMuNIBP9Syuu1gBwyHIUIL64oADn7DMuhv6OcogdaMj6DH97J/kltd7xaL4t+W3yMVbXEMTdjKS8UbDUj/s60h5wCW0ic3pc2fKSff2carCqBg49H/ChJzR0gvWSilIYehOZyotFsQgVNrOoofRDMCTjQYchDGPjJx3Mvzcm1/1hsyOvHTfs4wCkwmFYcLk577vrTtSjUFZ8/JC5SMGlRQqAkAojUZHDMaUibbnyTVeATqmefUG45Zcw0xp2sDFruPOHsdwtRh47MaRjD4wrDYYIy0lT8eSa3bL1fSwKCAQEA6ghxJe5BxKogOK1GX6wLIZJ1nlbM3aXTPnsCyvZaF2RKbF+6jgqvWOfWM/4oj/rRNPuqi5vTRjusEyltXhLFTF9fEcL8zUL9ex3Vb3wxgqWnuc5GRPZCQGJX9oW67eu0OIRhlYl/TQ9INaelbUPa0ATDCshLi13v+uy6uyKLMbd8w+GQiJdgqnmbpdC9jTcbT4MxtMFVR7ocQ7vf4a5Xk4iUC9EACXjfkIpSQ7SeeHzvR0DUiv/HD4WtP4Fcvx+uQDt/5jFViM4Yxs4uvRB5CfogmLv36Hr5zo/lPftpUnpeVSud/lhfljSow15eZjIS+8/NqlUYvkgcZbcmawviNQKCAQEAhpKYX9tUs3f312xbFAPXpXz0yMk8VpeYnrtxGNUjslfGJgqBAtCiKjipP3QqjSQslyPq+LxFU2H7w7wN+srhoMjxlqIU8le+oXaLCxYFaRkdQU+vA/VkHON4w1tt3sSPTF/YMkY3K425T6U9we6vRf+p8n/9ccokJ/ClcYIiFMNL24HU5xT9oBgQKlJs0EudU3OHig9IzxRxzwFBDFeR38Dlax4XmCNheyWGTpWvbQNKsmKlH7YILhH+/DICyYnNzeCBBcYty8SRVC9o4g1YCUBx2vRmCiVsbOUoT2UGtp2bswxDC1M/+kR9YQLmNHYwCODeAkBpKxTDRLR4ZdqYowKCAQA1RpyzXMyd/3h8Tn2xs9GI3/VkiS/z2RcApzIYkAIsRwlmKFiokygdnhE2HsqPFDLh09ScGWn8GANxDUI3YyCE5UUYHwI7m99mUoFO8r+2lQ1cj+eRNVoZnAmYNhM6rCiHoSMxzm4rVapDhJl1CThbmGnqH3SLEmRaA9/yT8fOFo4RbVzgq003IZ3cHmu4JO5TqHL9SfGm9WgPx0oM7wpCrJm/IuHWRizmk4ZsoUZd+VrjJo/74IQpNW4eAc3iOE0LlD/mYB6vmPMs9qzPH1veeJFJE6k4xB3v9vPhq0TroK2ux9Icn3OLFwvABdCJhSarKkAQYXTThEjqosndHoRtAoIBAQDvZeR+zHEc38fB5dhVtdix4NXcliM3YfT2Q+3rHPnpY+bwKNe+JaOMi68HoE4W8047G89xdd/B3tGSj7Q9bN1vAvaCqeu5zNriVKVEW5kqh9C6nb064bUCXCHSrRLbTxHFamKXGQa1aVlcCDAEiUhadYEVrR09EN6hFL918/uW52N67b98Zs7D5/pF3pT9H6eOYJxrm/ls4a84B+NtX1RMnX1sx9nFHCRGYtMAWK/zxmqxJb7++1c5smydcNi4uKoOEPIKiiKbdZvnuxw4T1ub0K+Mv9dkMuJApbHltFh0JVLwJGHg3z1m6kWBQA69iw0FQ/ICf4fbi+xvkKQuSZCM-----END PRIVATE KEY-----

Using OpenSSL we can calculate the hashes of this pair to see that they match:

Public Key:

$ openssl x509 -noout -modulus -in | openssl md5(stdin)= f4ef82e22bed048e5c48b4da5e46afa7

Private Key:

$ openssl rsa -noout -modulus -in | openssl md5(stdin)= f4ef82e22bed048e5c48b4da5e46afa7

We can also use Openssl to validate that this certificate is revoked. First getthe CRL URL from the certificate:

$ openssl x509 -noout -text -in | grep -A 4 'X509v3 CRL Distribution Points'    X509v3 CRL Distribution Points:         Full Name:          URI:

Download the CRL:


Transform the CRL to a PEM file:

$ openssl crl -inform DER -outform PEM -in COMODORSADomainValidationSecureServerCA.crl -out COMODORSADomainValidationSecureServerCA.crl.pem

We also need the full certificate chain. In this case it you can get it fromComodo. I've placed it in theCOMODORSADomainValidationSecureServerCA.pem file. The openssl verify commandneeds this concatenated together with the PEM CRL file to be able to do a CRLcheck. Concatenate the two PEM files:

$ cat COMODORSADomainValidationSecureServerCA.crl.pem COMODORSADomainValidationSecureServerCA.pem > CA_CRL.pem

Perform the actual certificate validation.

$ openssl verify -crl_check -CAfile CA_CRL.pem OU = Domain Control Validated, OU = PositiveSSL, CN = xs4all.nlerror 23 at 0 depth lookup:certificate revoked

If we would validate the certificate without the CRL check it would turn outvalid:

$ openssl verify -CAfile COMODORSADomainValidationSecureServerCA.pem OK

If you want to this manually, you can try it like more verbosely. First get theCRL from the certificate:

$ openssl x509 -noout -text -in | grep -A 4 'X509v3 CRL Distribution Points'    X509v3 CRL Distribution Points:         Full Name:          URI:

Download the CRL:


Get the serial from the certificate:

$ openssl x509 -noout -serial -in serial=5284469DBF7A0940D3C48A95AF2E8B06

Find out if the serial number is on the CRL:

$ openssl crl -inform DER -text -noout -in COMODORSADomainValidationSecureServerCA.crl | grep -A 1 5284469DBF7A0940D3C48A95AF2E8B06    Serial Number: 5284469DBF7A0940D3C48A95AF2E8B06        Revocation Date: Mar 20 04:32:29 2015 GMT

As we see it is, the certificate has been revoked.

Tags: blog, dane, hpkp, security, ssl, tls, tlsa