Advanced SSL: Intermediate Certificate Authority and deploying embedded boxes

Question

Ok Advanced SSL gals and guys - I'll be adding a bounty to this after the two-day period as I think it's a complex subject that deserves a reward for anyone who thoughtfully answers.

Some of the assumptions here are simply that: assumptions, or more precisely hopeful guesses. Consider this a brain-teaser, simply saying 'This isn't possible' is missing the point.

Alternative and partial solutions are welcome, personal experience if you've done something 'similar'. I want to learn something from this even if my entire plan is flawed.

Here's the scenario:

I'm developing on an embedded Linux system and want its web server to be able to serve out-of-the-box, no-hassle SSL. Here's the design criteria I'm aiming for:

Must Haves:

• I can't have the user add my homegrown CA certificate to their browser
• I can't have the user add a statically generated (at mfg time) self-signed certificate to their browser
• I can't have the user add a dynamically generated (at boot time) self-signed certificate to their browser.
• I can't default to HTTP and have an enable/disable toggle for SSL. It must be SSL.
• Both the embedded box and the web browser client may or may not have internet access so must be assumed to function correctly without internet access. The only root CAs we can rely on are the ones shipped with operating system or the browser. Lets pretend that that list is 'basically' the same across browsers and operating systems - i.e. we'll have a ~90% success rate if we rely on them.
• I cannot use a fly-by-night operation i.e. 'Fast Eddie's SSL Certificate Clearing House -- with prices this low our servers MUST be hacked!'

Nice to Haves:

• I don't want the user warned that the certificate's hostname doesn't match the hostname in the browser. I consider this a nice-to-have because it may be impossible.

Do not want:

• I don't want to ship the same set of static keys for each box. Kind of implied by the 'can't' list, but I know the risk.

Yes Yes, I know..

• I can and do provide a mechanism for the user to upload their own cert/key but I consider this 'advanced mode' and out of scope of this question. If the user is advanced enough to have their own internal CA or purchase keys then they're awesome and I love them.

Thinking Cap Time

My experience with SSL has been generating cert/keys to be signed by 'real' root, as well as stepping up my game a little bit with making my own internal CA, distributing internally 'self-signed' certs. I know you can chain certificates, but I'm not sure what the order of operations is. i.e. Does the browser 'walk up' the chain see a valid root CA and see that as a valid certificate - or do you need to have verification at every level?

I ran across the description of intermediate certificate authority which got me thinking about potential solutions. I may have gone from 'the simple solution' to 'nightmare mode', but would it be possible to:

Crazy Idea #1

• Get an intermediate certificate authority cert signed by a 'real' CA. ( ICA-1 )
  • ROOT_CA -> ICA-1
• This certificate would be used at manufacturing time to generate a unique passwordless sub-intermediate certificate authority pair per box.
  • ICA-1 -> ICA-2
• Use ICA-2 to generate a unique server cert/key. The caveat here is, can you generate a key/pair for an IP (and not a DNS name?)? i.e. A potential use-case for this would be the user connects to the box initially via http, and then redirects the client to the SSL service using the IP in the redirect URL (so that the browser won't complain about mismatches). This could be the card that brings the house down. Since the SSL connection has to be established before any redirects can happen, I can see that also being a problem. But, if that all worked magically
• Could I then use the ICA-2 to generate new cert/key pairs any time the box changes IP so that when the web server comes back up it's always got a 'valid' key chain.
  • ICA-2 -> SP-1

Ok, You're So Smart

Most likely, my convoluted solution won't work - but it'd be great if it did. Have you had a similar problem? What'd you do? What were the trade offs?

Befuddle

May be you still can use plain HTTP for uploading private root CA or server self-signed certificate to user's browser? It can be done as "one-click" (ok, not one but very easy) process at server installation time. Is "no HTTP, no cert install" really MUST have? – Aurar

Unfortunately the 'must haves' are based on negative responses about the current solution of having to click-through with a self-signed cert. But after speaking with a couple of our customer advocates it's apparently as bad as shooting the customer's dog. It is a pain in the ass, and not helped by Firefox's increasing cranky-old-man attitude about self-signed certs. Thats kinda what has me shooting for the stars, there has to be a better way. auth_digest doesn't solve it, SRP-TLS gets closer for some aspects but it's still bleeding edge with regards to support. – Befuddle

Answer 1

Basically, no, you can't do this the way you hope to.

You aren't an intermediate SSL authority, and you can't afford to become one. Even if you were, there's no way in hell you'd be allowed to distribute to consumers everything necessary to create new valid certificates for any domain, trusted by default in all browsers. If this were possible, the entire system would come tumbling down (not that it doesn't already have problems).

You can't generally get the public authorities to sign certificates issued to IP addresses, though there's nothing technically preventing it.

Keep in mind that if you're really distributing the private keys in anything but tamper-proof secured crypto modules, your devices aren't really secured by SSL. Anyone who has one of the devices can pull the private key (especially if it's passwordless) and do valid, signed, MITM attacks on all your devices. You discourage casual eavesdropping, but that's about it.

Your best option is probably to get and sign certificates for a valid internet subdomain, and then get the device to answer for that subdomain. If it's a network device in the outgoing path, you can probably do some routing magic to make it answer for the domain, similarly to how many walled-garden systems work. You could have something like "system432397652.example.com" for each system, and then generate a key for each box that corresponds to that subdomain. Have direct IP access redirect to the domain, and either have the box intercept the request, or do some DNS trickery on the internet so that the domain resolves to the correct internal IP for each client. Use a single-purpose host domain for that, don't share with your other business websites.

Paying more for certificates doesn't really make them any more or less legit. By the time a company has become a root CA, it's far from a fly-by-night operation. You should check and see if StartSSL is right for your needs, since they don't charge on a per-certificate basis.

Monodrama

On the matter of 'Only as secure as the physical hardware', I will concede that I agree and understand that aspect. The desire for the unique keys is to avoid the scenario where it's a single valid cert/key deployed on every box (resulting in the host mismatch problem) since once you get the private off one box you can decrypt every box. With regards to intermediate cert costs - I somewhat guessed that would be the case. I wish the EFF would start a not-for-profit CA. – Befuddle

If you're looking for a low-cost-per-cert CA, you want StartSSL (I thought you were making a dig at 'em earlier with the "fast eddie's..." stuff, so I didn't mention them). Their model verifies you, and then lets you issue as many certs as you need. Your use case is probably borderline for their terms, but I think it's on the ok side of the line. Is the custom subdomain model likely to work for your use case? – Monodrama

This is dead on. Because there isn't a tech soluion, you are going to have to handle it in sales or support. Someone needs to tell the customer what the ssl options are in such a way that they are encouraged to get a non-self signed cert. Heck, I'm sure you could partner with someone to offer it in app and take a piece of the sale as a referall. – Dubose