Category Archives: ssl hell

Certificate Impossible

Posted on by

I’m writing an iOS app.  Loving it too, learning a lot.  More on that in a bit.

Today when I tried to update my github repostory, I received a certificate error that said “XCode can’t verify the identity of the server github.com”.  Because I’m a paranoid idiot, I decided to get to the bottom of it.   A search on Stack Overflow scared the crap out of me — the “accepted” answer is to just “make the prompt go away” by blindly choosing to trust the certificate.  That is theoretically the worst, laziest, most insecure answer in the world and we as an industry should be castigating such a brutal security recommendation, right?  But before casting stones, what *should* be done?

Here’s what I found about the intermediate certificate presented by github:

  • The intermediate certificate that shows up in the certificate chain given by github.com is called “DigiCert High Assurance EV CA-1”.
  • It was issued Nov 9 2006, expiring Nov 9 2021.
  •  It has a SHA-1 fingerprint of 4A 35 8B 25 35 28 61 42 F6 0F 4E 9B 57 E2 AE 11 6D AB F0 F5.
  • It was issued by a CA certificate called “DigiCert High Assurance EV Root CA” with a serial number of “08 BB B0 25 47 13 4B C9 B1 10 D7 C1 A2 12 59 C5”.
  • The certificate gets a little green checkmark to say that the certificate is valid.  I assume this means that the certificate passed CRL and OSCP checks

 

To try to clear this up, I went to the Digicert website, to their root certificates page at https://www.digicert.com/digicert-root-certificates.htm, to validate this intermediate certificate.  I downloaded the certificate called “DigiCert High Assurance EV CA-1” and confirmed that the downloaded cert matched what was shown on the website:

  • There is an intermediate cert on the website called “Digicert High Assurance EV CA-1”.
  • It has a SHA-1 fingerprint of DB C7 E9 0B 0D A5 D8 8A 55 35 43 0E EB 66 5D 07 78 59 E8 E8.
  • It was issued Nov 9, 2007, expiring Nov 9 2021.
  • It was issued by a CA certificate called “DigiCert High Assurance EV Root CA” with a serial number of “03 37 B9 28 34 7C 60 A6 AE C5 AD B1 21 7F 38 60”
  • The certificate gets a little green checkmark to say that the certificate is valid.  I assume this means that the certificate passed CRL and OSCP checks

So,  where does this leave us? Let’s just recap.

  • I get a warning about a certificate when I try to use XCode to go to github.
  • When I view the certificate, the operating system pronounces the cert as “valid”.
  • Neither the thumbprint nor the issuer serial number match the values advertised by Digicert as the correct values for that intermediate CA certificate.

So what is an honest but paranoid person supposed to do now?   The chain presented by github both fails when XCode looks at it programatically (not that I can tell you exactly why the programmatic fail occurs) and when I attempt to manually validate.

It is very possible that Digicert has issued two intermediate CA certificates.  For example companies define rollover certificates all the time, so that there is always one valid certificate for business continuity.  But given that both these certificates expire on the same date, these particular certificates kinda suck as rollover certificates.   If DigiCert had reissued the CA certificate due to fraud or misadventure I would *hope* that one of these two certs should fail CRL and OSCP checks.  But that hasn’t happened either.

Conclusion: Based on the resources available to me, I have to conclude that the intermediate certificate offered by github is evil.  Either that, or Digicert has wasted a bunch of my time by not simply documenting the second thumbprint for the second valid instantiation of the intermediate certificate.

If the former is true, I have no idea what to do.  If the latter is true, I still have no idea what to do.  Color me completely unable to move forward.  Yay security.

For the 2 people who actually bothered to read this to the end, here is a screenshot of the three certificate detail screens for the intermediate certificate — the leftmost cert is the intermediate certificate from the github error, the middle cert details are from the intermediate cert downloaded from Digicert directly, and the rightmost window is the DigiCert details window.   Fill your boots. Any recommendation on how I could actually move forward here short of emailing digicert support would be gratefully accepted.  I’ll let you know what I find out from my email to support@digicert.com.

 

 

 

Firefox 3 Rocks the Certificate Error Page

Posted on by

I’ve just upgraded to Firefox 3 – and I’m really glad to see that the developers have made the ceremony around suspicious certificates both more informative, and much more strongly worded.

I love to see this kind of progress. Server names deleted to protect the innocent.

Firefox 3 Certificate Errors

And the Winner is…

Posted on by

I have an SSL certificate for my domain. And it took mere minutes and not a single extra email conversation to be validated.

The winning SSL Vendor took the approach that if I’m in control of my domain, I should also be in control of a few standard domain email addresses. A verification was sent to one of those email addresses. I responded to it. Done. And I didn’t even go through the parent company – I went through a reseller, and the process was still flawless (and cheaper).

What a night-and-day difference in customer experience. Talk about creating brand loyalty…

SSL Vendor X, I love thee not

Posted on by

Rule #1 in this girl’s Guide to the Internet is: Never post your home address. Whether you are a 14-year-old in a chat room or a 30-something girl geek registering a domain, it makes sense to keep that information private.

In keeping with that rule, I use my work address when registering my own domains. Other people I know use post office boxes. I do not consider such a thing as bizarre or unexpected behaviour. As long as I can receive postal mail at the specified address, I do believe that I have satisfied the original registration requirement.

Unfortunately, at least one SSL vendor does not agree. I attempted to get a certificate for my domain yesterday, and ran into a wee little roadblock. Sadly, there is no trust relationship between the company that I registered my domain with, and the company I attempted to get a certificate from. The only method that the SSL vendor has instituted to ensure that I own my domain is to demand an exact match of address information between a submitted copy of a real-world credential and the WHOIS database entry for my domain:

Dear Pamela Dingle,

Thanks for writing to us.

We like to inform you that, according to validation we
follow the below process:
1. Inorder to activate your account, we need any of
the supporting documents exactly to match with the
account details.

2. And for issuing certificate, we need the account
details to match with whois.

Alternatively, you can change your account details for
which you can provide the documents.

We look forward to your response.

As it is highly unlikely that I will be able to produce a copy of an “official” document containing my work address, the only alternative that the SSL company is willing to entertain is for me to update my WHOIS information with my home address, so that it matches my drivers license. I consider that unacceptable, and I think it is a perfect example of users being railroaded into placing more information than they want into the public domain. Yes, I could temporarily change my information to my home address to get the cert and change it back. Yes, I could probably get my company to request the certificate, because we’re a small company and because I have a nice boss. That isn’t the point.

The point is that most people will do what the vendor asks, because they are being held hostage. They want SSL. They are told they have no other options. It is easier to accomodate under duress, than to stand up and say no.

I think that there are other options. The goal shouldn’t be to prove where I live, but to prove that I have control over the domain. I could, for example, change my WHOIS data to say “SSL VENDOR X SUX”. Besides making me feel better, I think it would prove some measure of control over my domain, but just in case, I could set it to a mutually agreed upon string. That would be a lot tougher to spoof than oh, say a photoshopped drivers license, yes? Ideally, wouldn’t it be great if the SSL company could receive an assertion from the company I registered my domain with, attesting to the fact that I own the domain? I’d like to see that happen.

Until then, SSL Vendor X can stuff it, and I will try and find a vendor who will take my money and treat information I wish not to disclose with a little more respect. Wish me luck.