
Embedded Devices Share, Reuse Private SSH Keys, HTTPs Certificates - walterbell
https://threatpost.com/embedded-devices-share-reuse-private-ssh-keys-https-certificates/115494/
======
mschuster91
Hmmm... for the HTTPS certificate. Assuming that a router exposes itself as
"myrouter.box" in the LAN and the manufacturer obtains a CA-signed cert for
it, it would not be a problem for the private key to be public?

At least in consumer space, the only threat I believe to be reasonable is your
kids running an ARP poison attack to get the admin password of the router and
unlocking the internet firewall - and any parent relying on technology instead
of properly educating their kids deserves being owned that way imho.

~~~
hannob
It is not possible to get a CA-signed cert for internal domains.

~~~
dogma1138
It was possible it was banned in 2011 by the cabforum. It was deemed that it
would more likely be exploited for malicious purposes rather than anything
else, and since you cannot explicitly validate the ownership of local domains
it pretty much creates a FCFS environment which can fail very easily due to
the inability to validate domain existence.

Internal sub domains e.g local.mycorp.com are still valid as long as you can
provide proof of ownership of the parent domain, and after the "ban" they also
introduces some leniency in getting an intermediate singing cert for internal
domains because in many cases the reason why a company would buy a "CA" cert
for an internal domain / host was regulatory and auditors don't care what the
cabforum has to say.

Those CA's however will not be distributed outside of the organization so they
pretty much provide as much assurance as an internal self signed CA just with
the ability to please an auditor by saying that it was signed by verisign.

~~~
throwaway7767
> after the "ban" they also introduces some leniency in getting an
> intermediate singing cert for internal domains because in many cases the
> reason why a company would buy a "CA" cert for an internal domain / host was
> regulatory and auditors don't care what the cabforum has to say.

Wait, so you're saying that CAs are giving out intermediate roots to customers
on the promise that they won't give out the private key? If this is the case,
please provide examples of CAs that do this, so I can open bugs in the
relevant software to request the root CAs be removed.

TrustWave did this, and got a lot of flack for it. In the end they stated it
was a mistake and they'd never do it again, so they got to keep their cert (a
mistake in my opinion, as they already demonstrated that they can't be trusted
with CA powers).

Or did you mean they provide regular server certs or wildcards for internal
domains?

~~~
mschuster91
Isn't it possible for a CA cert to have authority only for *.foo.com?

~~~
throwaway7767
> Isn't it possible for a CA cert to have authority only for *.foo.com?

Technically, you can do that with name constraints. In practice, you can't
because many SSL implementations (like, say, OpenSSL[0]) won't honour it, so
it'd effectively be an unrestricted root CA for those.

[0] [http://blog.codekills.net/2012/04/08/adventures-
in-x509-the-...](http://blog.codekills.net/2012/04/08/adventures-in-x509-the-
utterly-ignored-nameconstraints/)

------
tkinom
If I am to set up an embedded device for distribution to outside customers,
and would like to setup https and/or more secure ssh private keys.

What's the best way to set it up?

Is it possible with current CA/https system?

