Anyone who has found themselves shopping around for "SSL certificates"[1] will have wondered what criteria to use, besides price, to compare the products. As any number with a currency sign attached is bound to draw attention, it's impossible to have missed the so-called warranty – especially since it ranges from a few thousand dollars to several million. It then becomes only natural to consider including this warranty into your comparison chart.

I must admit the first few times I bought a certificate I looked at the number, shrugged and moved on – after all, the purchase was for personal projects and I was only interested in two things: a generally trusted certificate authority and the lowest possible price I could find. However, when I repeated the exercise for a business, I paid a little bit more attention to the details. The warranty stood out, yet it made little sense. So I dug around and, with a little bit of luck and perseverence, I found the legal documents that govern this elusive warranty. Of course, if anyone throws "$1,750,000 warranty" in your face when you're looking at a $249 purchase, without any explanation whatsoever on what that's supposed to represent, your marketing-gimmick-alarm-bells should start ringing. The warranty agreements[2][3] (which, thankfully, weren't that long or exhausting to read) certainly proved my instincts were right. I'm going to use Comodo's to illustrate my point.

  1. The buyer of the SSL certificate isn't even the entity covered by the warranty; the "relying party" is. As Comodo's legal team eloquently puts it: "A party using the Certificate to conduct an online transaction using a credit card with the Subscriber named in the Certificate." Which translates to someone entering their credit card details on a web site. This is made quite clear in a clause: "Under no circumstances shall any third party, including the Subscriber[4], be a third party beneficiary with respect to the Warranty."
  2. It's not necessarily your customers making purchases on your site that are protected, either. It only covers fraudulent transactions where an incorrectly issued certificate played a role. For example, if someone manages to get Comodo to issue a certificate for amazon.com without proving to Comodo that they are the owners or in control of the amazon.com domain name, then somehow make use of this digital certificate to intercept a victim's credit card details, then said victim would be covered. The first part is certainly a certificate authority's responsibility to avoid ever happening. The second part requires the attacker to be in a privileged network position – either capable of intercepting at least some traffic between the victim and the target web site or having infected the victim's device. After all, they have to use that certificate somehow. Interestingly, the agreement includes exceptions when the loss is caused "wholly or partially" by: "acts by any unauthorized individuals which impairs, damages, or misuses the services of any Internet Service Provider or telecommunications, cable, or satellite carrier, other common carrier or value-added services, including but not limited to, denials of service attacks and the use of malicious software such as computer viruses".
  3. The warranty only covers the amounts lost in fraudulent transactions which were not refunded by the credit card issuer. The transaction needs to have been disputed to the credit card issuer "in compliance with the rules, procedures, and time-lines applicable". Only if the entire sum isn't recovered through this, does the warranty kick in.
  4. The victim must have rather advanced technical knowledge, because they must have "verified the Certificate and reasonably relied on the information contained in a Certificate validated by Comodo to establish the identity of the Certificate holder". I'm not sure if outsourcing this responsibility to the browser, which most (if not all) of us do, is sufficient. I'm not quite sure how this can be verified by the certificate authority, either.
  5. Before entering any credit card details on a web site, an end-user must enter into an agreement with the certificate authority: another condition is for the relying party to "read and agree to be bound by the Relying Party Agreement, the terms of this Warranty, and the Comodo CPS prior to using the Certificate or providing any credit card information to the Subscriber".

And that is just a summary. Overall, I'm fairly certain that the terms were designed so that the certificate authority will never, under any circumstances, have to pay anything under this warranty. In my research[5], I was unable to find any instances when a CA would have paid out. And while I wouldn't call the warranty a scam, this, in my opinion, means its only purpose is to mislead – a good example of marketing at its worst.

There's a bit of good news, however. Experience has taught us that if a certificate authority issues certificates incorrectly, its days are bound to be numbered. In an early high-profile case, DigiNotar found itself taken over by the Dutch government and declared bankrupt the same month its problems were discovered. More recently, WoSign (including StartCom, which it had previously acquired) has been discredited by the major browsers[6]; later that year, StartCom terminated its operations[7]. Around the same time and for similar reasons, Symantec, one of the biggest names in the business, was effectively forced to sell its CA operations to a competitor, DigiCert[8]. In the end, this means a misbehaving certificate authority has a much higher price to pay than the flimsy "warranty".


  1. Technically, they're X.509 certificates suitable for SSL/TLS servers. But everyone calls them SSL certificates, so who am I to argue? ↩︎

  2. Thawte Relying Party Agreement ↩︎

  3. Comodo Relying Party Warranty ↩︎

  4. The Subscriber is the entity that purchased the certificate. ↩︎

  5. To be honest, I'm not an investigative journalist, so my research skills leave a bit to be desired. ↩︎

  6. Google Chrome's HTTPS ban-hammer drops on WoSign, StartCom in two months ↩︎

  7. Termination of the certificates business of Startcom ↩︎

  8. Google to kill Symantec certs in Chrome 66, due in early 2018 ↩︎