News for hackers. Stuff that matters.
Re:Let's Encrypt Overview by derefr on Friday June 12, 2015 @03:02PM (#9707896)
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?

Re:Let's Encrypt Overview by mike_hearn on Friday June 12, 2015 @03:57PM (#9708170)
> 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.

Re:Let's Encrypt Overview by what_the_diffie on Friday June 12, 2015 @10:51PM (#9709694)
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.
Re:Let's Encrypt Overview by icebraining on Friday June 12, 2015 @03:10PM (#9707938)
I believe that's the point of the Name Constraints property, but from what I can tell it's generally ignored.
Re:Let's Encrypt Overview by JoshTriplett on Friday June 12, 2015 @04:12PM (#9708240)
In particular, there are enough stacks that ignore it that it would be unsafe to issue a CA certificate even with nameConstraints.
Re:Let's Encrypt Overview by grahamedgecombe on Friday June 12, 2015 @05:31PM (#9708686)
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.)
Re:Let's Encrypt Overview by dtech on Saturday June 13, 2015 @06:01AM (#9710503)
So then you've jumped from the frying pan into the fire, since your cert now will not work in those implementations.
Re:Let's Encrypt Overview by bkeroack on Friday June 12, 2015 @03:43PM (#9708111)
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).

Re:Let's Encrypt Overview by baby on Friday June 12, 2015 @06:08PM (#9708872)
do modern browser accepts wildcard certificates though?
Re:Let's Encrypt Overview by bkeroack on Friday June 12, 2015 @07:19PM (#9709150)
If you mean a certificate for something like *.domain.com, then yes, every modern browser that I'm aware of will validate it properly.
Re:Let's Encrypt Overview by baby on Friday June 12, 2015 @03:19PM (#9707982)
They only sign leaf certs
Re:Let's Encrypt Overview by marcosdumay on Friday June 12, 2015 @04:56PM (#9708486)
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.

Re:Let's Encrypt Overview by baby on Friday June 12, 2015 @06:02PM (#9708839)
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.