Raymii.org

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

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

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

❗ This post is over nine years old. It may no longer be up to date. Opinions may have changed.

What happened
How does SSL validation work
How can we prevent this
Certificate Transparency
- HTTP Public Key Pinning (HPKP)
- DNS based authentication of Named Entities (DANE)
Proof

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 email alias. In this article I'll explain what happened, why that was possible and how we 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 a pre-specified set of email addresses. I was able to register one of those email addresses (administrator@xs4all.nl). With that email address, I was able to receive a validation link for a certificate.

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

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

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

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

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

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

alias

How does SSL validation work

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

The CA/Browser forum, the standards body for Certificate Authorities has set baseline requirements which describe exactly how these validations should occur. 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 that email alias.

Domain Validation certificates

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

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

If the CA uses the Internet mail system to confirm that the Applicant has authorization from the Domain Name Registrant to obtain a Certificate for the requested Fully-Qualified Domain Name, the CA SHALL use a mail system address formed in one of the following ways:

Supplied by the Domain Name Registrar;
Taken from the Domain Name Registrant's "registrant", "technical", or "administrative" contactinformation, as it appears in the Domain's WHOIS record; or;
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 can provide domain ownership to the certificate provider.

Organization Validation

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

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

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

Extended validation

An Extended Validation, or EV certificate is a certificate where the browser displays a green bar with the company name. This certificate has the highest level of validation behind it.

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

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

How can we prevent this

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

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

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

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

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

There are a few ways to mitigate this problem. Certificate Transparency, Public Key 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 would support this then my certificate would be unusable. I'll cover a few of these measurements 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 to scrutiny by domain owners, CAs, and domain users. Specifically, Certificate Transparency has three main goals:

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.
Provide an open auditing and monitoring system that lets any domain owner or CA determine whether certificates have been mistakenly or maliciously issued.
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 provide faster detection of mis-issued certificates and rouge CA's, plus faster mitigation of issues like these. It is a very interesting project, read the website 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 a whitelisted public key. It ensures only whitelisted Certificate Authorities (CA) can sign certificates for *.example.com, and not any CA in your browser store.

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

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

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

If the bank implements HPKP and pin's their first intermidiate certificate (from CA Company A), browsers will not accept certificates from CA Company B and CA Company C, even if they have a valid trust path. HPKP also allows your browser to 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 and provides 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 used in that domain's TLS clients or servers by [storing them in the Domain Name System (DNS). DANE needs DNS records to be [signed with DNSSEC.

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

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

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

This is the TLSA record for xs4all.nl, port 443:

$ dig +dnssec +noall +answer +multi _443._tcp.www.xs4all.nl. TLSA
_443._tcp.www.xs4all.nl. 21599 IN TLSA 1 0 1 (
                                223A6659D06E9A81390938659E9EF241579E82B820D6
                                AFD8E17D548AEDEA3F13 )

If we take the current, valid, public key for xs4all.nl we can validate this.

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 I got it gives us a different SHA 256 hash:

$ openssl x509 -inform PEM -in xs4all.nl.pem -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 DNS record holds what is called Certificate Association data. In conjunction with DNSSEC signatures, this will permit better and more secure ways for applications to authenticate certificates. The record can be used in 4 different ways (defined by a "Usage" field):

(Usage 0) Specify authorized public CAs - this can prevent certificates signed by CAs that you didn't explicitly specify from being trusted by client software.
(Usage 1) Specify which specific server certificate can be trusted. The public CA certificate validation chain all the way to the server certificate must still be validated.
(Usage 2) Authorize a new non-public CA (eg. a CA that the domain owner operates itself)
(Usage 3) Directly specify the server certificate in the DNS - no certificate chain from a public CA needs to be used. This is called a "Domain issued certificate"

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

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

Proof

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

$ openssl x509 -noout -text -in xs4all.nl.pem 
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, CN=xs4all.nl
        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: 1.3.6.1.4.1.6449.1.2.2.7
                  CPS: https://secure.comodo.com/CPS
                Policy: 2.23.140.1.2.1

            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://crl.comodoca.com/COMODORSADomainValidationSecureServerCA.crl

            Authority Information Access: 
                CA Issuers - URI:http://crt.comodoca.com/COMODORSADomainValidationSecureServerCA.crt
                OCSP - URI:http://ocsp.comodoca.com

            X509v3 Subject Alternative Name: 
                DNS:xs4all.nl, DNS:www.xs4all.nl
    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 xs4all.nl.pem
-----BEGIN CERTIFICATE-----
MIIGPzCCBSegAwIBAgIQUoRGnb96CUDTxIqVry6LBjANBgkqhkiG9w0BAQsFADCBk
DELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1
UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxNjA0BgNVBAM
TLUNPTU9ETyBSU0EgRG9tYWluIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBDQTAe
Fw0xNTAzMjAwMDAwMDBaFw0xNjAzMTkyMzU5NTlaME0xITAfBgNVBAsTGERvbWFpb
iBDb250cm9sIFZhbGlkYXRlZDEUMBIGA1UECxMLUG9zaXRpdmVTU0wxEjAQBgNVBA
MTCXhzNGFsbC5ubDCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOPUpIn
AWGzv8AuzlwPF8jeztIxZLZxQBDcEL7Ax36Hn+m14JT0a4QxIfU6vO/9X1+UZhf59
+P6QM6CwS44bqYZLanBw97Qi3pBimY+6QowgY3QWXSkjTwjh4g9zFw/0I/OGa0wkC
sEonc+Cc59QWRLMFWC7V2RxE2+zBDgzWdOfZ84HDoUiohlTURt2PEDJS6IMFAUQb/
Kzbmy2laZgF9EvvLcZsFoZspik6RC2bmRo9EKd47J6F+lLzZmNqwFYj2m6oi7iVAa
ZqHIUcaXzJZuBknoMZ5tzXBGoaZYbmWVfZJZB9JF1tybPqCugKNwzkCB6fpdy4HyT
6SKjuCiEWAj6OxcI6MTOZ9RQI1wOfp0MP/GMQVODfG6yxH3F+2jLpQackY08nS4gl
jvEsfrtWMI3/h6oisnqo0ldjWC+iGgnKsxu4+9VI4V6/K3tLw4xA8cQut0Smohd71
guVOd4alhoO+N4vA+IPrM8LgWeVGyh2+KbAb7mkp2nIk1JF+F4uspq/p7/0oCAr3u
gEBcqV/Ex5PA4iEsMYggYxYoqGKwMtdKzSuLU3ly6d9RemaEZqwvngqZp6+vimSCb
vIRq9Lywh3icshIPNlf6c+ziZJBbasgyaTu2Tvh9xTYIE4uwYA+QB5nEoP6iudLjM
GtNnO1+LqLXxFIBDt1phxIijfCHAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBSQr2
o6lFoL2JDqElZz30O0Oija5zAdBgNVHQ4EFgQUKlP+GFwjyZGkcWpp/rDbb3krQ9g
wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUH
AwEGCCsGAQUFBwMCME8GA1UdIARIMEYwOgYLKwYBBAGyMQECAgcwKzApBggrBgEFB
QcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLmNvbS9DUFMwCAYGZ4EMAQIBMFQGA1
UdHwRNMEswSaBHoEWGQ2h0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUR
vbWFpblZhbGlkYXRpb25TZWN1cmVTZXJ2ZXJDQS5jcmwwgYUGCCsGAQUFBwEBBHkw
dzBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBR
G9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNydDAkBggrBgEFBQcwAYYYaH
R0cDovL29jc3AuY29tb2RvY2EuY29tMCMGA1UdEQQcMBqCCXhzNGFsbC5ubIINd3d
3LnhzNGFsbC5ubDANBgkqhkiG9w0BAQsFAAOCAQEAM9ZRhzy1fymnWElURXPI3qtB
zWwTbcTnyLSF3bJtkTR7ddlxForneRqyFn+u1SphHWy+CxCvG8+ntn5RfEkgB9orq
ixyG3Crasqtjrp7mPpeEkC0y4/dNRY7i7QUWVaMMrxbNDbU/DrWh3Nw7+X+Q89VPV
PY7CvKBhtyjWrCX0xGprQSGgv/+EChIWMxpkDGncNnxj8obha2OcqEZA2389wvdsp
aYwwjK1rSfRPVd40kOP6sc5Ze+pHfNm6+TpxSxpLz9Kb+RUc75FJt3wl2WFApD7kA
gL83MG4ysIDWl7ood3DwL6Bm/5OodIm0XTlXPtooTgZIoWyB/eHwWstUXQ==
-----END CERTIFICATE-----

Here is the private key:

# cat xs4all.nl.key 
-----BEGIN PRIVATE KEY-----
MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQDj1KSJwFhs7/AL
s5cDxfI3s7SMWS2cUAQ3BC+wMd+h5/pteCU9GuEMSH1Orzv/V9flGYX+ffj+kDOg
sEuOG6mGS2pwcPe0It6QYpmPukKMIGN0Fl0pI08I4eIPcxcP9CPzhmtMJArBKJ3P
gnOfUFkSzBVgu1dkcRNvswQ4M1nTn2fOBw6FIqIZU1EbdjxAyUuiDBQFEG/ys25s
tpWmYBfRL7y3GbBaGbKYpOkQtm5kaPRCneOyehfpS82ZjasBWI9puqIu4lQGmahy
FHGl8yWbgZJ6DGebc1wRqGmWG5llX2SWQfSRdbcmz6groCjcM5Agen6XcuB8k+ki
o7gohFgI+jsXCOjEzmfUUCNcDn6dDD/xjEFTg3xussR9xftoy6UGnJGNPJ0uIJY7
xLH67VjCN/4eqIrJ6qNJXY1gvohoJyrMbuPvVSOFevyt7S8OMQPHELrdEpqIXe9Y
LlTneGpYaDvjeLwPiD6zPC4FnlRsodvimwG+5pKdpyJNSRfheLrKav6e/9KAgK97
oBAXKlfxMeTwOIhLDGIIGMWKKhisDLXSs0ri1N5cunfUXpmhGasL54Kmaevr4pkg
m7yEavS8sId4nLISDzZX+nPs4mSQW2rIMmk7tk74fcU2CBOLsGAPkAeZxKD+ornS
4zBrTZztfi6i18RSAQ7daYcSIo3whwIDAQABAoICAQDba9qjyJnhIRyhSG9y9NuZ
BfwnB2REHVRR4DhFi2MEPbUUZRgIR7Di8ZWtiFtSSrnlLbW9Knn6QctXQTMjRET6
z/tNG5+U39hWWn/mys54wmDGVxuWGSlvNo1Pr9pQRSOy0IzaIgQxj/qc9diBYRLI
ZcFZDlTWqYi8lT7FGb+zbty8slMrqfVQSsvclPzmsHelM9i8H96RcnoxPY/XUsjd
cQphld4giItXM8w7ile7YNGOrx2ysKAC0jzLXIOLok1M2LCGUvf1+1sds87YstpP
cHUwEm5earYLU5WNOjt8RGlNxWvUA/lG6cvfaDqyCP8QKKlvFvZZROLNt7wPWZam
DV5a4o7RnVXflLQ7/asQwhIKq38T43q2MwhSA7uCcXTWAxcrJAXVyZ5viAh4tCcz
wiydGzzFR52jmYrvYuGjmFxO0YiPHy4+XqwXDQEjIR2eaUq46lTM0F6MCp/pWpIT
Ygd0cHcJYNCbUB6ondkw4nB8ZWB3Tuc+jlXc8c3Jkic8P4UaxtsCjHJ8eLt+7/TY
/rD9N0dbfmRF0Aq5Dbv4lxAfdz3yt+OcYJ5yQ26MlHPjyds/sv1I0HU8vPY+9xaA
S07xU0rF2Iv+BF3LSv4MbMICGmKtsBAZseAxCSmPQ5nbU7R64xADgq59CfgLTx2k
KAMBuNMo1nbbgWgAstnGcQKCAQEA+TcqTL/YwTUdCiaLt8xKK+KWyACsdGDXcSVK
GUMvV4/3EnGjMuNIBP9Syuu1gBwyHIUIL64oADn7DMuhv6OcogdaMj6DH97J/klt
d7xaL4t+W3yMVbXEMTdjKS8UbDUj/s60h5wCW0ic3pc2fKSff2carCqBg49H/ChJ
zR0gvWSilIYehOZyotFsQgVNrOoofRDMCTjQYchDGPjJx3Mvzcm1/1hsyOvHTfs4
wCkwmFYcLk577vrTtSjUFZ8/JC5SMGlRQqAkAojUZHDMaUibbnyTVeATqmefUG45
Zcw0xp2sDFruPOHsdwtRh47MaRjD4wrDYYIy0lT8eSa3bL1fSwKCAQEA6ghxJe5B
xKogOK1GX6wLIZJ1nlbM3aXTPnsCyvZaF2RKbF+6jgqvWOfWM/4oj/rRNPuqi5vT
RjusEyltXhLFTF9fEcL8zUL9ex3Vb3wxgqWnuc5GRPZCQGJX9oW67eu0OIRhlYl/
TQ9INaelbUPa0ATDCshLi13v+uy6uyKLMbd8w+GQiJdgqnmbpdC9jTcbT4MxtMFV
R7ocQ7vf4a5Xk4iUC9EACXjfkIpSQ7SeeHzvR0DUiv/HD4WtP4Fcvx+uQDt/5jFV
iM4Yxs4uvRB5CfogmLv36Hr5zo/lPftpUnpeVSud/lhfljSow15eZjIS+8/NqlUY
vkgcZbcmawviNQKCAQEAhpKYX9tUs3f312xbFAPXpXz0yMk8VpeYnrtxGNUjslfG
JgqBAtCiKjipP3QqjSQslyPq+LxFU2H7w7wN+srhoMjxlqIU8le+oXaLCxYFaRkd
QU+vA/VkHON4w1tt3sSPTF/YMkY3K425T6U9we6vRf+p8n/9ccokJ/ClcYIiFMNL
24HU5xT9oBgQKlJs0EudU3OHig9IzxRxzwFBDFeR38Dlax4XmCNheyWGTpWvbQNK
smKlH7YILhH+/DICyYnNzeCBBcYty8SRVC9o4g1YCUBx2vRmCiVsbOUoT2UGtp2b
swxDC1M/+kR9YQLmNHYwCODeAkBpKxTDRLR4ZdqYowKCAQA1RpyzXMyd/3h8Tn2x
s9GI3/VkiS/z2RcApzIYkAIsRwlmKFiokygdnhE2HsqPFDLh09ScGWn8GANxDUI3
YyCE5UUYHwI7m99mUoFO8r+2lQ1cj+eRNVoZnAmYNhM6rCiHoSMxzm4rVapDhJl1
CThbmGnqH3SLEmRaA9/yT8fOFo4RbVzgq003IZ3cHmu4JO5TqHL9SfGm9WgPx0oM
7wpCrJm/IuHWRizmk4ZsoUZd+VrjJo/74IQpNW4eAc3iOE0LlD/mYB6vmPMs9qzP
H1veeJFJE6k4xB3v9vPhq0TroK2ux9Icn3OLFwvABdCJhSarKkAQYXTThEjqosnd
HoRtAoIBAQDvZeR+zHEc38fB5dhVtdix4NXcliM3YfT2Q+3rHPnpY+bwKNe+JaOM
i68HoE4W8047G89xdd/B3tGSj7Q9bN1vAvaCqeu5zNriVKVEW5kqh9C6nb064bUC
XCHSrRLbTxHFamKXGQa1aVlcCDAEiUhadYEVrR09EN6hFL918/uW52N67b98Zs7D
5/pF3pT9H6eOYJxrm/ls4a84B+NtX1RMnX1sx9nFHCRGYtMAWK/zxmqxJb7++1c5
smydcNi4uKoOEPIKiiKbdZvnuxw4T1ub0K+Mv9dkMuJApbHltFh0JVLwJGHg3z1m
6kWBQA69iw0FQ/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 xs4all.nl.pem | openssl md5
(stdin)= f4ef82e22bed048e5c48b4da5e46afa7

Private Key:

$ openssl rsa -noout -modulus -in xs4all.nl.key | openssl md5
(stdin)= f4ef82e22bed048e5c48b4da5e46afa7

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

$ openssl x509 -noout -text -in xs4all.nl.pem | grep -A 4 'X509v3 CRL Distribution Points'
    X509v3 CRL Distribution Points: 

        Full Name:
          URI:http://crl.comodoca.com/COMODORSADomainValidationSecureServerCA.crl

Download the CRL:

wget http://crl.comodoca.com/COMODORSADomainValidationSecureServerCA.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 from Comodo. I've placed it in the COMODORSADomainValidationSecureServerCA.pem file. The openssl verify command needs this concatenated together with the PEM CRL file to be able to do a CRL check. 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 xs4all.nl.pem 
xs4all.nl.pem: OU = Domain Control Validated, OU = PositiveSSL, CN = xs4all.nl
error 23 at 0 depth lookup:certificate revoked

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

$ openssl verify -CAfile COMODORSADomainValidationSecureServerCA.pem xs4all.nl.pem 
xs4all.nl.pem: OK

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

$ openssl x509 -noout -text -in xs4all.nl.pem | grep -A 4 'X509v3 CRL Distribution Points'
    X509v3 CRL Distribution Points: 

        Full Name:
          URI:http://crl.comodoca.com/COMODORSADomainValidationSecureServerCA.crl