Short-Lived Certificates at Netflix
medium.facilelogin.com
medium.facilelogin.com
You can use it as a standalone project in your environment as well. There's a talk about it at https://youtu.be/Q_ZhrQq-_YM (ideas very similar to Netflix)
Sadly let’s encrypt does not support wildcard... and support for intranet is controversial to thosr who want to keep their intranet “totally private”. I love the autobot. One command to generate new cert, another command to reload my Nginx.
So, I expect existing CAs (and groups like InCommon) will continue to be around to serve large entities.
Such as?
You want to limit the exposure of your certificates, you don't want 50+ teams to share credentials/certs (they're effectively public at that point), and you want to make sure that if you need to revoke the certificate right now, you know you're impacting as few endpoints as possible.
For server-side caching, some systems now take into account SNI hostname and use it to prevent contamination. If you're in this situation, it's worth looking into how exactly your backend works.
https://translate.googleusercontent.com/translate_c?depth=1&...
The big problem here is that the intermediate CA isn't really limited on what they can grant. You can issue a valid "google.com" cert just as well as "foo.yourcompany.com". The are x509 extensions for limiting the scope in this case, but I don't believe they're widely used or validated at the moment.
This used to be not that big of a deal with hundreds of larger companies having subCAs but the rules have tightened up considerably. Apple and Google have them under one of the Symantec roots, but a lot of older ones have been deactivated. The reason is that the root CA is responsible for ensuring you're doing as good a job of issuing as they would have, since they're effectively "sponsoring" your issuance, promising you're doing it right, and that costs money. As a rule of thumb if your organisation doesn't have an actual full-time role sorting out all the certificates, you won't find it cheaper to have any subCA status. "But I spend like an hour every week doing it" is not a full-time role.
The cheapest option if you do have a subCA is a constrained subCA that's hosted. In this scenario the CA:TRUE certificates says inside it that it is only valid for certain hierarchies and mustn't be trusted outside those, this is called a "constraint". The root CA has to make sure such a subCA is properly looked after but they can do this internally themselves, so they'll want it on their server premises, not in your DC or under somebody's desk, where they can vouch for its security.
A more expensive option is still hosted but without the constraints. In this case the subCA can issue any certificate, but it does so under direct supervision of the root CA operator, often using only IT built by them. So e.g. there's a web site, you sign in, you tell it what certificates you want and then _they_ check that's OK before using "your" subCA to issue. The root CA has to do lots of extra paperwork for this scenario, but it's not so bad because they need most of the same things for their existing business, they get a sort of economy of scale on the audits, lawyers, building security etcetera.
The most expensive is on-premises unconstrained. In this case you have no limits. And so you also have to obey all the same rules as the root CAs do. This means third party auditors have to visit as witness to various routine activities, and their audit reports including adverse findings must be submitted to your root CA and to the major trust stores as a requirement of their trust. You will need a dedicated, physically secure building to house the hardware security module of the CA function, with properly trained staff following documented procedures, "No Lone Zone" policies, all that jazz. This can definitely cost a million dollars per year to sort out _before_ you pay anybody to let you do it.
Also by the way "Verisign" you're thinking of, the root CA, was sold to Symantec, who are now selling to DigiCert and the Verisign roots are to be distrusted (which is part of why Symantec are selling, they destroyed trust in these roots through a poorly managed approach to the business).
Ideally even separate certs for every subdomain, but as Let’s Encrypt has cert limits, and I want to avoid SNI in the future, I’ll probably have to use wildcard certs.
SNI transmits the host unencrypted, that is a real security issue.
Systems that hostname their customers (mycompany.example.com) should use wildcards for that scenario instead of SNI, among other reasons. That’s the only possible concern I can imagine.
Multi domain certs help but then you need to encode all the names ahead of time and if you miss a name you need to reissue and reapply the cert.
Otherwise an adversary could simply see what IPs you connect to and reverse DNS them.
Back dating with a technical rationale (e.g. to work around crap clocks and historically as a way to hide more entropy near the start of the signed certificate) is accepted in the Web PKI, it is only forbidden to use back dating to try to dodge Baseline Requirements, for example back dating to avoid the restriction on SHA-1 after 2015 was prohibited and is one of the things StartCom / WoSign were caught doing.
Maybe this is what you meant but you can do it in a single command. For example:
certbot renew --post-hook "service nginx reload"you still pay for x years certificate, but you only get a valid certificate for the next y days. if the CA can sign OSCP responses for millions of visitors, surely they can resign a certificate every y days.
>the world was mostly manual in the past (and in a lot of places still is)
that makes sense when talking about OSCP, but to get OSCP stapling working, you need to configure your web server to do so. instead of standardizing OSCP stapling, why couldn't they have standardized a protocol for a server to get updated certificates from the CA?
That's essentially OCSP :-)
In general there's not really a concept of an "updated certificate". A certificate is good if the signature matches, the subject on the cert matches the server, and the current time is within the certificate's validity period; otherwise, the cert is bad. If someone steals a certificate, the website fixes this by telling the C.A. to revoke the certificate and by serving a different valid cert – my old employer kept a second valid certificate lying around in order to minimize downtime in the event of having to kill the main cert. OCSP is a way to effect the killing of the bad certificate. But in the absence of OCSP or some other revocation mechanism both certs are still good.
> if the CA can sign OSCP responses for millions of visitors, surely they can resign a certificate every y days.
I haven't worked on this stuff in a few years, but historically OCSP resolvers were notoriously unreliable and often down. That's a huge issue for a security-critical path, because you're forced to "fail open" (which defeats the whole point of having OCSP in the first place) or render a wretched experience for your user. One big reason OCSP stapling exists is to work around C.A. OCSP resolvers' unreliability.
I was on the Credhub team for a while. When you begin to assume that you have (1) an always-on credentials service and (2) that it can serve multiple sides of credentialling (eg, service broker adds a credential, application fetches it), you get to do more aggressive cred management.
I was on the Credhub team for about 6 months, while it was being worked on both US coasts. It's now based in NYC.
[0] https://github.com/cloudfoundry-incubator/credhub/tree/maste...
[1] https://builttoadapt.io/the-three-r-s-of-enterprise-security...
For anyone interested in tracking the progress of ACME 2.0, take a look here: https://datatracker.ietf.org/doc/draft-ietf-acme-acme/
Disclaimer: *I work for ManageEngine.