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 seven years old. It may no longer be up to date. Opinions may have changed.
Table of Contents
Click the image to see the certificate.
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
firstname.lastname@example.org). 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.
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.
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 "184.108.40.206. 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.
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.
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.
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.
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: 220.127.116.11.4.1.6418.104.22.168.7 CPS: https://secure.comodo.com/CPS Policy: 22.214.171.124.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:
$ openssl x509 -noout -modulus -in xs4all.nl.pem | openssl md5 (stdin)= f4ef82e22bed048e5c48b4da5e46afa7
$ 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:
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
Download the CRL:
Get the serial from the certificate:
$ openssl x509 -noout -serial -in xs4all.nl.pem 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