[SSL Observatory] https://controller.mobile.lan

Brian Keefer chort at smtps.net
Tue Feb 7 09:28:27 PST 2012


On Feb 6, 2012, at 6:19 PM, Dean Coclin wrote:

> This is Dean from Symantec. I'd like to offer the following with regard to
> your question about this certificate:
> 
...
> Customers have approached VeriSign with a similar need: they produce an app
> or appliance that is to be deployed in their customer's network, and they
> want out-of-the-box SSL certificate protection. Since they cannot know in
> advance what will be the host name that their customer will provide for the
> app or appliance (and they don't wish to burden their customer with the task
> of generating and 
> installing an SSL certificate after installation), they purchase an SSL
> certificate for an internal-only domain name, and deploy the same private
> key and certificate in each app or appliance.
> 
> Dean Coclin

The same *KEY*? I see it has already been pointed out, but that's an incredibly bad idea. It only takes one device breach + trip to pastebin, or one "helpful" customer and the default configuration of every device is compromised.

I'm also not clear on how having a certificate for a non-existant, non-matching hostname helps, even if it's chained to a trusted root. How is that better than generating a self-signed cert on the fly that matches the actual hostname a customer assigns to the device? Is there a good reason to not have each device generate a unique key & CSR when the installation is performed?

I'm really struggling to understand why signing an invalid cert is the "right" approach for this use case, other than the fact that it generates a bit of revenue and automatically generating self-signed certs does not.

--
bk





More information about the Observatory mailing list