Hacker News new | past | comments | ask | show | jobs | submit login

My experience is from 10 years ago, where I set this up for a startup I worked at. This was the situation: we had built a platform for trade finance. It was like eBay but for trade paper. eg. somebody is exporting $80M worth of oil, and they need a bank to finance it. We had 500+ banks from around the world on the platform, and they would all bid for the business.

Because we were dealing with hundreds of millions of dollars worth of commitments, we needed a certificate architecture that would verify the seller, the buyer, and for each of those parties to verify the site.

I went to Verisign and asked them for the best solution, and this is what they setup:

- we had a Verisign terminal setup in the office. This was a normal computer, but locked down to only run Verisign software. It was a flavor of UNIX

- the terminal had a smart-card reader on it, and a private net connection that went only back to Verisign.

- the authentication to login to the computer was two passwords, both with secure tokens, and two smart cards

- when you login, you do the ID shuffle, which involved two people who had background checks conducted on them etc.

- we generate a certificate, which is then signed using a sub-CA certificate that Verisign issues to us

- Our certificate thus acted as a CA, but it was authorized by Verisign, so the certs that we signed would then check out using the built-in browser CA certs

This cost us hundreds of thousands of dollars to setup, and cost us hundreds of dollars for each cert we signed. When I did the due dilligence on the solution, I visited 3 london-based banks who had implemented the same system. The selling point was that we could act as a CA, but without really being a CA.

Verisign's sales pitch was that you could never become the root CA because of the stringent policies that had to be put in place (isolated networks, key generation, etc.), but for the fraction of the cost, we could sign certs using our cert which would be verified up the chain to the root CA which was Verisign

I can't stress how secure this whole procedure was. The root CA store was the holy grail - nobody that did't have the infrastructure or procedures like Verisign would get anywhere near it. I now read stories 10 years later of dodgy dutch companies with no budgets being given root CA privileges, and I am just blown away.

If these guys needed a solution to sign certs, they should have been setup with what we had, and what the other banks had, not just given placement in the root cert store. Verisign would check and double-check everything we did, and would frequently revert certs we signed where they suspected something was wrong.

With this story it seems there was a completely amateur operation given privileges to sign certs as part of a root CA.

I have 163 root CA certs on my OS X machine. 10 years ago I am certain the number was 4 or 5

note: this was so long ago that I probably have some of my terminology mixed up, but what we bought was the right to sign certs as a sub-CA of Verisign, a privileged root CA. I also got a very cool tour of Verisign which is another story.




So the only thing that kept your startup from being able to mint a certificate for *.GOOGLE.COM was the physical security of a single Unix box?

The setup you describe is actually worse than what happened with Diginotar. There's a public record of Diginotar being added to the browser roots, complete with audit statements tying PwC to attestations that Diginotar was ready to be a CA. Nobody in hindsight agrees that a good decision was made there, but at least we know it was made.

There is no way to account for Verisign signing CA=YES keys for private companies as a convenience; we can only trust Verisign when it says "anything we do with our private key we do with security measures adequate to the task of protecting the entire Internet". Well, I don't want to pin the safety of the entire Internet on Verisign's ability to secure a Unix box they don't even have physical custody over.

Diginotar isn't what upsets me about the browser CA situation. Subordinate CAs are.


It wouldn't insta-sign. It would go back to Verisign and they would do authorization against our client database. They called the client every time and did a number of checks.

We were just acting as an intermediary CA, which I think is a better setup than a bank acting as a root CA (as Wells Fargo et al are now) since we had Verisign looking over our shoulder seeing which certificates we signed and not being afraid to revoke

So as I saw this situation, if they were setup as an intermediate CA, when the signing went up the chain it would have been noticed - rather than a cert being signed and instantly being verified by all browsers


The way I read his tale, it sounds like VeriSign may have kept the signing keys for his intermediate CA, and their onsite secure terminal just submitted CSRs back to VeriSign and got the signed certificates back. VeriSign was then in a position to enforce the policy that no certs get signed for anything outside of the domains that should be signed.


I thought so too, but then I read "can't be a root CA because of stringent policies, isolated networks, key generation" and felt he was writing about the weird machine they put on their prem.


>we can only trust Verisign when it says "anything we do with our private key we do with security measures adequate to the task of protecting the entire Internet".

like we trust with the same to any other CA in the browser trusted root store.


Exactly.

We could with the flip of a switch ban intermediate CAs; the browser's TLS library sees the chain of intermediate CA=YES certs.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: