Hacker News Reader

Comment by derefr | Hacker News Reader

Question: is the X.509 system set up in such a way that one of these issuers could give me a free code-signing cert, or a free CA cert for signing client certificates?

Because, as far as I understand, the answer is no: signing certs have no sense of signing "for an origin". If a CA issued me a CA cert, I could use it to create a signed cert for microsoft.com. Which seems nonsensical.

All I want is to get issued a CA cert that lets me sign arbitrary things within my domain's scope. Basically, the X.509 equivalent of a DNS NS record, delegating responsibility for making assertions about that domain (and only that domain) to "my" CA. Why is that so hard?

View on HN

> Why is that so hard?

It's hard because for the longest time (e.g. between 1995 and about 2010) nobody really cared about SSL. It was a box you ticked when implementing a login form or a credit card purchase page. So the infrastructure was neglected, progress was lethargic and generally everything bitrotted.

This can be seen quite clearly in the state of OpenSSL, in the number of exploits in TLS stacks that started appearing in recent years once academic attention was focused on them, etc.

The feature you want is called name constraints and for the longest time was not really implemented anywhere. So that's why CAs don't do it. Also: this would be a highly niche feature and CAs, like any businesses, weigh up implementation cost vs potential market size and risk when choosing what to support.

That doesn't mean it will never happen. It could, now there's a lot more focus on the SSL infrastructure in the wake of Snowden.

Also, openssl didn't (or doesn't) appear to care about high-reliability software engineering and the IETF TLS Working Group didn't care about producing a minimum-featured spec that is not overly difficult to implement, maintain and support in the real world. Instead, TLS has become a kitchen-sink, feature-hoarding, experiment-in-production jambalaya.

I believe that's the point of the Name Constraints property, but from what I can tell it's generally ignored.

In particular, there are enough stacks that ignore it that it would be unsafe to issue a CA certificate even with nameConstraints.

X509 extensions can be marked as critical. Certificates must be rejected if the stack encounters a critical extension it doesn't understand. (In theory at least, I haven't looked at real implementation behaviour.)

So then you've jumped from the frying pan into the fire, since your cert now will not work in those implementations.

As icebraining wrote, it's technically possible with X.509, but nobody within the public CA industry will do it for business reasons.

You could approach the problem by creating your own root CA for the domain and then issue subordinate CA certs, but obviously for clients to validate them they would need to import your root into their trusted store (in a corporate IT scenario you would push out the root as part of the domain policy).

do modern browser accepts wildcard certificates though?

If you mean a certificate for something like *.domain.com, then yes, every modern browser that I'm aware of will validate it properly.

They only sign leaf certs

No, they don't.

That's one of the several elephants on the room with the CA system. They issue non-leaf certs with a big frequency for people like the GP, with a honest reason to want them.

x509.CreateCertificate is used to creat the certificate (https://golang.org/pkg/crypto/x509/#CreateCertificate)

and is called by the CFSSL library, that has isCA = false as default (https://github.com/cloudflare/cfssl/blob/152152bec641f502651...)

Also it is verified that the CSR doesn't contain that field in Boulder: https://github.com/letsencrypt/boulder/blob/aa71088c440a63e1...

This test is called when you send the CA a CSR: https://github.com/letsencrypt/boulder/blob/08ac100788c7edaf...

I don't know for other CAs, but from that quick look of the code boulder doesn't seem to sign certificates that can sign other certificates.

Reply on news.ycombinator.com