|
I think that we can surely say that, with all its deficiencies, SSL/TLS is still a protocol we cannot live without, and basis of today’s secure communication on the Internet. Quite often I get asked on how certificates are really verified by browsers or other client utilities. Sure, the canned answer that “certificates get signed by CA’s and a browser verifies if signatures are correct” is always there, but more persistent questions on how it exactly works happen here and there as well. So, if you ever wondered on how a certificate could be fully manually verified by checking all the steps, this is a diary for you! In this example we will manually verify the certificate of the site you are reading this diary on, https://isc.sans.edu. We will use the openssl utility so you can replicate all the steps for any certificate on any machine where you have openssl. Here we go. In order to get the certificate we want to verify we can simply connect to https://isc.sans.edu with the openssl utility. For that, the s_client command will be handy and it will print out the certificate in PEM format on the screen so we just have to catch it and put it into a file: $ openssl s_client -connect isc.sans.edu:443 < /dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > isc.sans.edu.pem The isc.sans.edu.pem file now contains the certificate from isc.sans.edu. We could try to verify it with openssl directly as shown below: $ openssl verify -verbose isc.sans.edu.pem Hmm, no luck. But that is because the CA file that comes with Linux by default is missing some of the intermediates. Those either have to be in the CA store, or the server has to deliver the whole chain to us when we initially connect. Ok, not a problem – let’s continue manually. $ openssl x509 -in isc.sans.edu.pem -noout -text Ok, so the certificate is valid, and it is signed by Comodo, as you can see in the highlighted line. The part that matters to the browsers is actually only the CN component. In the Subject field we can see that the CN matches our site (isc.sans.edu) and in the Issuer field we can see that that signing CA (which is an intermediate CA) is called COMODO RSA Organization Validation Secure Server CA. We can verify this information in the RFC2253 format as well, for both the subject and issuer; this will be easier to read: $ openssl x509 -in isc.sans.edu.pem -noout -subject -issuer -nameopt RFC2253 So, let’s first try getting the CAcert file that is used by Mozilla. This might help us verify everything. That being said, getting the CAcert file from Mozilla is not all that trivial and some extractions/conversions should be done. Luckily, the good folks at curl already publish the cacert file in the PEM format so we can get it from their web; it’s available at https://curl.haxx.se/docs/caextract.html $ curl https://curl.haxx.se/ca/cacert.pem -o cacert.pem The file even contains name of CA’s in plain text. Let’s search for Comodo: $ grep -i Comodo cacert.pem It doesn’t have the one that we need: remember that it must match precisely to the CN field! This also confirms that it is an intermediate CA. We will probably have to find the intermediate CA’s certificate on Comodo’s web site. Let’s paste the name into Google (“COMODO RSA Organization Validation Secure Server CA“) and see what we get. The first hit will lead us to https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/968/108/intermediate-ca-2-comodo-rsa-organization-validation-secure-server-ca-sha-2 and sure - this is were our intermediate CA is. Let’s download it: $ curl 'https://support.comodo.com/index.php?/Knowledgebase/Article/GetAttachment/968/821025' > comodo.crt Now let’s check the issuer and subject here as well: $ openssl x509 -in comodo.crt -subject -issuer -noout -nameopt RFC2253 Great! That’s exactly what we need – see that the Subject field (the CN component) matches exactly to the signer of our certificate. We are lucky even with the issuer: $ grep "COMODO RSA Certification Authority" cacert.pem It is a root CA, that exists in Mozilla cacert.pem – so we have the full chain! $ openssl x509 -in isc.sans.edu.pem -noout -text | grep Signature Ok, SHA256 with RSA (great job Johannes on renewing the cert properly :)). What does this mean? This means that the critical parts of the certificate have been hashed by the CA with the SHA256 hashing algorithm and then encrypted with CA’s private key. It’s public key is available in the comodo.crt file we just downloaded (and isc.sans.edu’s public key is in the certificate we got from the web site). Openssl can confirm that as well for us: $ openssl x509 -in isc.sans.edu.pem -noout -text What we need to do know is the following:
In order to extract components of a certificate we need to decode it to ASN.1 format. Luckily, openssl can do that for us, so let’s see what we get on isc.sans.edu’s certificate: $ openssl asn1parse -in isc.sans.edu.pem So, the last object is actually the signature – it starts at offset 1597, so let’s extract it with openssl: $ openssl asn1parse -in isc.sans.edu.pem -out isc.sans.edu.sig -noout -strparse 1597 Now we got the file isc.sans.edu.sig, which is RSA encrypted SHA256 of the signature. How do we decrypt it? We need Comodo’s public key, which is available in its certificate, so let’s extract it: $ openssl x509 -in comodo.crt -pubkey -noout > comodo.pub Now that we have the Comodo’s public key, we can finally decrypt the SHA256 hash. It will work only if the original has been encrypted with the corresponding private key. We’ll get an ASN.1 structure back so let’s show it properly as well on the screen: $ openssl rsautl -verify -pubin -inkey comodo.pub -in isc.sans.edu.sig -asn1parse Yay, it worked. So it has been encrypted properly. The highlighted part is actually the SHA256 hash. $ openssl asn1parse -in isc.sans.edu.pem Ok, the first object starts at offset 4, let’s extract it the same way as before: $ openssl asn1parse -in isc.sans.edu.pem -out tbsCertificate -strparse 4 The file tbsCertificate contains what we need to run SHA256 has over. We can again use openssl for that: $ openssl dgst -sha256 -hex tbsCertificate Remember the decrypted ASN.1 object? Scroll up – or let me paste it here one more time (this diary is already longer than I thought really): … Yay! It’s a full, 100% match. So the certificate is correctly signed by Comodo’s intermediate. We could now repeat all the steps to verify if the intermediate CA is correctly signed by the root CA that we got from Mozilla’s cacert.pem, but we can also have openssl do that for us, we just need to tell it with CA file to use: $ cat comodo.crt >> cacert.pem And that get’s us to the end of verification. -- Bojan |
Bojan 355 Posts ISC Handler |
| Reply Subscribe |
Jul 28th 2016 10 months ago |
|
You must get paid by the hour instead of being on salary.
 If it's an Internet-accessible site try these: https://www.ssllabs.com/ssltest For SMTP servers try http://www.checktls.com. If you use the More Detail button it gives you everything you need and more. They actually use OpenSSL to derive those results. Hmmm, the SMTP servers for isc.sans.org and isc.sans.edu do not have TLS encryption enabled but there are MX records? Tested with abc@isc.sans.org and .edu isc.sans.edu has a soft-fail SPF record instead of a hard-fail and isc.sans.org doesn't even have an SPF record yet it has MX records? Domains that do not send email should have an SPF record of v=spf1 -all sans.org has a p=none DMARC record, which is understandable because of the soft-fail on its SPF record. I do not fully agree with the recent Krebs article on email security but the presence of that article should be a wake-up call for all organizations to double-check their email configurations. Perception = Reality, unfortunately. |
Anonymous Posts |
| Reply Quote |
Jul 28th 2016 10 months ago |
|
Nice write-up...
Also for us overworked (or is that lazy) I like: https://testssl.sh/ (All credit to @drwetter) |
Chuck 2 Posts Posts |
| Reply Quote |
Jul 28th 2016 10 months ago |
|
Easier ways to find the intermediate certificate:
a. use the -showcerts command in the openssl s_client command. b. get it from the url in the Authority Information Access field in the end entity certificate. |
brian 4 Posts Posts |
| Reply Quote |
Jul 28th 2016 10 months ago |
Sign Up for Free or Log In to start participating in the conversation!
