This post is the first of two that I will be publishing over the coming days to address a few concerns that seem to be rising in the wider community. It was recently pointed out to me that my certificate authority doesn't provide me with a warranty on the certificates they issue me. This post outlines why I don't care, and why you shouldn't either.


Certificates with insurance or warranties

Yes, you heard that right, your certificates might just come with its own insurance policy or warranty. I guess if your certificate breaks down and has to be recovered to the garage you don't want to get hit with a nasty repair bill!


comodo-warranty


rapidssl-warranty


Jokes aside though, this is a big thing often pushed at the point of sale of certificates and is something that is constantly thrown at me when people argue against the free Let's Encrypt certificates that I use on my blog and other services. A "commercial CA" will offer you insurance or a warranty and a "free CA" won't. To me this just doesn't sound like a valid concern but let's break it down and take a look at exactly what's being offered and how it can be used.

There are 3 main scenarios that I see covered by these 'warranties' where they could pay out if something bad happened.


  1. If the information in the certificate was not correct.
  2. If the CA discloses the associated private key for the certificate.
  3. A consumer suffers financially because of a mis-issued certificate.

Let's start with number 1 on that list and we can pretty much immediately throw that out. All CAs are required to validate the subscriber according to the terms set out in the Baseline Requirements from the CA/Browser Forum. We already have a mechanism with which to enforce this. The further problems with this point also tie in with point 3, so we can cover those together in just a moment.

Item number 2 on this list is also easy to protect against, the CA should never, ever, have had access to your private key, it's plain and simple. No one but you should ever be in possession of that key. You send the CA a CSR to sign and they never posses nor have access to the private key, only the public key. I don't think we need to clarify this point any further because it simply should never be possible, and if it is, you're doing something else drastically wrong.

That leaves us with the 3rd point and seems to be the most commonly known or discussed point from my own experiences. If a CA mis-issues a certificate and a consumer suffers loss due to that mis-issuance, the CA will pay out. To give you a scenario there let's use my site, https://report-uri.com, and walk through it. Report URI takes payments for services from customers, but an attacker manages to breach or trick a CA into issuing a certificate for report-uri.com. The attacker then uses that certificate to trick innocent consumers into visiting a fake website and giving up their credit cards details which are then used for fraudulent transactions. In this scenario the CA offers to re-imburse the consumer because the site was using a mis-issued certificate. Let's take a look at just a few ways this doesn't work.


  1. The user saw nothing wrong or out of the ordinary in the browser and typed in their credit card details, so how would they know to associate a valid but mis-issued certificate with the fraud?
  2. How would the user prove they were subject to an attack using the mis-issued certificate. You'd need traffic logs and a copy of the cert, at a minimum.
  3. This provides no protection to me as the owner of Report URI. I bought this certificate but my CA pays out to consumers if they are impacted. Why do I need to pay for a certificate with a warranty so my CA covers someone else's losses in the event that the CA screws up and causes those losses? They should be doing that anyway...
  4. My certificate has a warranty on it but in the event of mis-issuance it's the warranty of another certificate that pays out. As the genuine owner of report-uri.com I don't need a warranty on my certificate, only the attacker needs one on theirs.
  5. If an attacker compromises a different CA that does not offer insurance or a warranty, none of this matters and I have a warranty on my certificate that's useless. The other CA isn't going to pay out.

Various different CAs and resellers provide information on what the warranty means and, of course, there's hundreds of pages of legal jargon if you'd like to read through that too.


comodo-warranty-explanation
source


ssl2buy-warranty-explanation
source


sslshopper-warranty-explanation
source


The small print

Things, of course, do get particularly interesting when we start to dig a little deeper though. Reading through some of the terms and conditions of these warranties and you start to find even more scenarios when they don't pay out and ways that the warranty doesn't apply. Take a look at Symantec's NetSure Protection Plan, the name for their warranty program, and specifically section 5.1(d).


symantec-clause


In the event that they mis-issue a certificate, it doesn't matter how many people are affected, they can only claim the amount of the warranty limit in total, not per claim. Things do get worse too. This is DigiCert's Relying Party Agreement and they place some restrictions on the consumer that would quite simply never be met.


digicert-clause


I'm going to quote a section of that text here because it's in tiny print and I think it's important that we understand exactly what's being said here.


For Certificates, this includes checking to ensure that each Certificate in the
Certificate Chain is valid, unexpired, and non-revoked (by using any CRL or OCS information available). For Site Seals, this
includes verifying the Site Seal’s authorization and validity directly with DigiCert and receiving a clear confirmation that
the Subject was and remains authorized to display or use the Site Seal


As the user, before using the site, you have to inspect each certificate in the chain for revocation and expiration. Now, the browser should have us covered for expiration, you'd hope, but revocation, that's a whole other story. As I've talked about at length, Revocation Is Broken. That means that as a user of a browser you would have to manually go and actually look up the revocation information on the certificate, and yes, you must do this because your browser either won't do this at all or will do this with a soft fail check and if a network adversary is currently using a rogue certificate against you, you have no hope of the revocation check completing. This is easy for me to do though, I handle things like this day in and day out. Fire up a terminal window and do the following to connect to the site and output information on the connection.


openssl s_client -connect scotthelme.co.uk:443

Grab the PEM certificate delimited by the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- markers and save it to a file cert.pem. Then extract the address of the OCSP responder from the cert.


openssl x509 -noout -ocsp_uri -in cert.pem

That should give you an address like this http://ocsp.int-x3.letsencrypt.org which is where need to send our revocation check. Now you need the intermediate certificate for the site in question.


openssl s_client -connect scotthelme.co.uk:443 -showcerts

Copy the intermediate certificate, delimited by the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- markers, and save that to int.pem. Once you've got that we can now issue the revocation check.


openssl ocsp -issuer int.pem -cert cert.pem -url http://ocsp.int-x3.letsencrypt.org

If that works you will receive one of two responses. My current certificate has a good response returned because it's currently not revoked.


Response verify OK
cert.pem: good
        This Update: Feb 24 00:00:00 2018 GMT
        Next Update: Mar  3 00:00:00 2018 GMT

If the certificate was revoked, and you shouldn't accept it, it would say cert.pem: revoked instead of cert.pem:good. That's it, that's what you have to check for before you trust the certificate and the worst part is that this is just for the leaf certificate. There's going to be at least one intermediate certificate in the chain and a root certificate too. Now, if you're using Chrome or Firefox, and they're up to date, you might be ok with not checking the intermediate because those browsers have proprietary mechanisms for tracking intermediate revocation called CRLsets and OneCRL respectively. If you're not using one of these browsers, or they're not recently updated, it's probably best to not rely on that. The same goes for the root certificate too, except these are managed by the trust store on your device. If you're using Firfox then you're using the Mozilla NSS trust store and you need to update your browser and if you're using any other browser then you will depend on the trust store of the underlying OS, so you need to have your OS fully updated. That was a bit of a long winded explanation but I wanted to make the point of just how ridiculous the requirement that the user check the revocation status of all certificates in the chain really is. Oh and on top of that you have to verify any site seals, if present, properly. How the user is supposed to know any of this ahead of time, because learning of these requirements after the fact is useless, is quite beyond me. It doesn't end there though, there's more.


you gathered sufficient information to make an informed decision about the proper use of the authentication product


Your reliance on the site authentication product or service is reasonable based on the circumstances


You relied on the site authentication product or service when conducting an online transaction

That one is interesting because you're only covered if you're purchasing something with a credit or debit card it seems. Got your account hijacked? Not covered... I'm not sure where this focus on online transactions comes from but it's a common theme across the board.


You disputed the unauthorized charge with any applicable service provider in accordance with the conditions and terms of the service provider, but the service provider refused to reverse the transaction, issue a refund, or provide other reimbursement for the unauthorized charge.

This one is also interesting because any fraudulent payment made on a credit card will be re-imbursed by the card company. Given the online transaction requirement above, this alone almost completely nullifies the warranty.


You submit the claim via email to support@digicert.com within 60 days after the transaction occurs.

You have 60 days to realise that something bad has happened, dispute the payment with the service or card provider, conduct the investigation to determine that a mis-issued certificate was the culprit and then file a claim with the CA. Good luck.


providing additional information and granting rights of subrogation, if requested.


I could go on but I really don't think I need to. Just reading through the requirements of a few of these warranty documents has me thinking it's impossible to actually ever make a claim on the warranty. The other problem is that you, as the end user, need to read and understand all of the T&C documents of each CA if you ever hope to make a claim under one of their warranties in the future. If you hadn't read the DigiCert terms above, how would you ever meet them to make a claim? As a site operator you need to have a certificate from all CAs, because most of this doesn't even apply to you and your site if you're not a customer of a given CA.


How many successful claims have there been?

I'm not the only person that's asked this and there are questions on the security and software engineering StackExchange sites asking the same thing, with no answers or examples given. There's also a pretty good answer on Quora from a certificate reseller that doesn't really cast a great light on warranties either.



What I would like to see, one thing that would be great to see from CAs in general, is more transparency. Not the kind that will soon be enforced with Certificate Transparency, which can't come soon enough, but transparency around these warranties. We don't need specific information, perhaps just something like how many claims have been paid out, perhaps a total value for claims paid too. Just something to give us a little bit of information that there is actually a process going on here and that something is happening, not that these are just meaningless words on a website somewhere. The fact that I can't find a single documented case of someone successfully claiming on one of these warranties really doesn't fill me with confidence that they have any value at all. I'd like to call on any CA out there to come forward and provide information. They're the best source for this information and yes someone may be able to link me to a story of a warranty claim, and if you can then please do drop by the comments below, but things like this really are best coming from the organisation in question. Troy did actually make an effort to do this, but the CEO of CertCenter said we're just "nerds" from "nerdville", what do we know?



When the counter argument is ad hominem, the case is closed. There was also no response to the follow up from Troy to provide information or examples.



Lisa's Tiger-Repelling Rock

All in all, the idea of a warranty on a certificate just seems like some marketing fluff for the CA to add to their sales page. The chances of this being useful are close to non-existent and there doesn't appear to be a viable way for a consumer to prove the certificate was the cause anyway. In many ways this whole discussion made me think of Lisa's Tiger-Repelling Rock.



People are adamant that these warranties protect us and offer us real benefit, but no one can explain how or show me them working. Much like Lisa's Tiger-Repelling Rock, if we took them away, nothing would change.