I accidentally replied to author instead of list earlier.
This discussion came up on another list under the topics "really sub-
CAs for MitM deep packet inspectors? (Re: Auditable CAs)" and "if MitM
via sub-CA is going on, need a name-and-shame catalog".
Yes, it's done, and yes it's actually common. Here's some choice
excerpts from those threads:
>Start of the thread was that Greg and maybe others claim they've seen a cert
>in the wild doing MitM on domains the definitionally do NOT own.
It's not just a claim, I've seen them too. For example I have a cert
from such a MITM proxy. I was asked by the contributor
reveal any details on it because it contains the name and other info
intermediate CA that issued it, but it's a cert for google.com
packet inspection on a MITM proxy. I also have a bunch of certs from
label CAs that chain directly up to big-name public CAs, there's no
measure I can see in them anywhere that would prevent them from
under any name.
>The real question again is can we catch a boingo or corp lan or government
>using a MitM sub-CA cert, and then we'll know which CA is complicit in issuing
>it, and delist them.
Given that some of the biggest CAs around sell private-label CA certs,
end up shutting down half the Internet if you did so.
- Peter Gutmann
> Actually, more surprisingly, I've been told by those who manage
> something like this for our company, that even the reported
> number of padlocks that they issue and are expected to
> compensate the CA for is kept on the honor systemm--at least
> for the CA with whom we interact. (Or course, I'm assuming that
> the this CA retains the right to periodically do audits, etc.)
Concur. The standard sub-CA contracts contain a right to audit the
number of certs issued, like any enterprise-wide software license
agreement does include a right to audit used seats. Not once in over
years have I seen such an audit performed. There is no reason to
when you buy a sub-CA, the public CA's rep will work out a contract
gives you the right to use as many certs and more as you conceivably
could use given the application to which you plan to put the sub-CAs.
Keeping count of actual certs issued would only add cost to both the
sub-CA customer and the root CA provider. There is simply no business
case for auditing the number of certs issued.
Presumably, if you bought a sub-CA for in-house use and then started
selling SSL server certs on the Internet, the root CA would complain,
but I have never seen such a silly violation of a sub-CA contract. If
you wanted to issue certs to the world, just execute a reseller
Lastly, a brief comment on cost: some posts in this thread mentioned
annual rate of USD 50k for a sub-CA. That number is indeed the rack
for an in-house sub-CA with unlimited cert issuance. (Well,
the contract will have a limit of the sum total of your employees,
servers, plus a generous buffer).
The smart purchasing manager will pay less than USD 50k. My advice to
customers that operate in-house sub-CAs has long been to renew in
mid-December or otherwise towards the end of the root CA's fiscal
At that time the rep will give you an unlimited certs sub-CA renewal
USD 35k per year. If he balks, threaten to switch to one of the
competing root CAs. Depending on how far behind quota the rep is,
similar discounts might be had in the last week of each quarter.
- Lucky Green
>Matches my observations, especially when looking at CRLs of some small CAs
>(company internal). I had a hunch some of those revocations could be due to
>CA compromise, but from my point of view it is be only a speculation. I
>appreciate sharing your experience working with CAs, it gives me a bit more
>understanding in my guesswork how they operate internally :-)
So I'm going to invoke the Carl Ellison "if you think that's bad" rule
approximately as "whenever someone tells a horror story about PKI,
else will come along with 'if you think that's bad...'") and mention a
root CA that went out of business (I tracked its root key through
resales but I have no idea who has it now) where not only did no-ne
who was left know how to put reason codes in CRLs, there was no-one
actually knew how to issue a CRL. So if you had a cert from them you
much do whatever you wanted with it (until it expired naturally)
was no way to revoke it.
- Peter Gutmann
Practically, things seems to hinge on "What the buyer does with the
white-label CA". If one of those certs gets out into the wild, or is
used on people the company doesn't have control over (e.g. it's used
in an airport hotspot instead of internally at the large company) -
then shit will hit the fan. But noone I know of has seen that
happen. If they have, they kept their mouth shut, probably because of
contract or NDA.
I think Trustwave revoking these certs is a great sign*, and trust
their root cert more because of it. Likewise, I'm pleased with the
statement from Comodo.
* the catch is, they probably revoked them because something bad did
happen, and they went "Oh shit, we're never going to let something
like this happen again."