So as Mozilla has put a bullet in StartSSL’s head (causing mass problems with thousands of free users worldwide), I can see there is a big gap in functionality between LE and the more mature StartSSL offering.
Firstly, the requirement to validate every subdomain with LE is somewhat excessive. If you can validate the root domain (ie mydomain.com), it makes no sense to have to validate every subdomain of that (www.mydomain.com, mail.mydomain.com etc etc).
Request #1)
If a root domain is validated, allow certificates to be generated for any subdomain of that domain.
Secondly, I know its a widely held opinion, but 90 day expiry is almost taking the piss. StartSSL offered 1 year by default, and as of the last 6 months or so, allowed up to 3 years with Class 1 DV certificates.
As LE is the same classification of validation, there is no real reason to artificially limit certificates to 90 days.
Request #2)
Allow at least a 1 year validation window for SSL certificates.
While I’m using close to 30 StartSSL certificates, with the current state of CAs (including LE), I’m thinking of just moving various web servers to only non-encrypted versions instead of trying to massage them all into the LE way of thinking. However the two above requests would make LE much more useful as a certificate provider.
Yep - I read a lot of this - most seemed to agree that at least 1 year is a good option... The reasons give aren't technical reasons, but are certainly hand waving strawman arguments to justify the decision.
I think StartSSL/WoSign has done sufficient damage to their own business. Their blatant disregard to the guidelines that all other registrars follow can cause severe problems with the trust of all CAs if nothing was to be done to them.
Also, if you're going to blame Mozilla, don't forget Apple and Google who are also distrusting the CA.
There are many good reasons to do so, as are explained. While very few are technical, that they advance certain things that LE finds have the potential to further their goals makes them relevant to this service.
If you want to change the minds of the folks at ISRG (who run LE), then some reasonable suggestions on why your desires would work okay with the goals of the project are much more likely to gain traction than saying that a disgraced registrar always did it a different way.
I have a worry that there is a well established echo chamber that is of the opinion that 90 day certs is a good thing. The problem with echo chambers is that they only reinforce themselves.
There are many more valid reasons in the 400+ post thread on this - and all are valid - from IoT devices to systems that can't be managed - so I'm not going to try and recap this here.
The point is, StartSSL is now gone - and its widely acknowledged outside of the LE Echo Chamber that their free offering was fantastic. LE is not in the same class - and its getting close to the deciding time as to if LE will step up and offer something comparable, or continue to be a niche service for some uses.
That remains to be seen. They are free to run a competent and honest operation and reapply to Mozilla's trust store. They have also written something about dodging the consequences and issuing usable certificates soon, presumably by reselling another CA.
Although StartSSL's operations are rather off-topic.
I think you’re confusing this so-called “LE echo chamber” with the infosec community as a whole. I haven’t seen many infosec or Web PKI experts disagree with the fact that pushing for short-lived certificates is a good idea. In fact, I don’t recall any. Certainly, it would be easier for some use-cases until the tooling catches up, but keeping everything unencrypted would be easy too and no one is suggesting we do that.
Anyhow, I would suggest keeping the discussion on short-lived certificates in the existing thread, though most of these points have been brought up there before.
Your first request might happen, ACME leaves that decision up to CA policy. If wildcards are introduced at some point, that might be a possible implementation.
That being said, keeping things simple makes it harder to mess something up, so with the domain you authorize matching the domain that gets put in the certificate, the implementation is fairly simple. Once you start doing fancy things, you might end up mis-issuing certificates the way WoSign and Comodo did recently (with WoSign going from subdomain to parent domain, and Comodo issuing certificates for a Public Suffix because their system thought www. is special). I also don’t think anyone will prioritize a feature for use-cases with manual verification (I suppose with automation, which is what Let’s Encrypt wants you to use and pushes for, there would be no reason to care about this).
Short-lived certificates are a security gain. Period. There are usability tradeoffs, however, and those need to be considered. I'm confident that ISRG will work to find the right balance. If not, they will lose popularity and other offerings will compete. Competition is a great thing.
I have gone on record supporting an option for 1 year certificates, but not as a default.
Yeah, there are many issues with some devices that are designed around manual updates and not designed to be changed. LE isn't going to work with all situations, and trying to do so will lead to a really sub-par experience for everyone.
In some cases, these limitations can be worked around by creative scripting. In many cases, they cannot. Petitioning vendors to issue new devices or updates that support ACME will show interest to them and maybe help others or yourself in the future. Even if you can't use it with LE, encouraging an open API for certificates means other providers can get in as alternatives.
Well, except for the $30 per certificate revocation fee. The howling at that during the Heartbleed situation was quite a thing and likely kept some people from revoking their affected certificates when they really should have.
It's working very well for my personal needs and the needs of the company where I work. It seems to be a great solution for a number of other users. LE has support from a number of hosting providers that aren't in the certificate business, and there are even official plugins for Plesk and cPanel. It works great for FTP, IRC, Web, Mail (SMTP, IMAP, etc.) and many other purposes. Third-party tools even allow it to work with Microsoft Azure, Windows, and plenty of other platforms. If it doesn't expand beyond that, it's still a huge amount of coverage and handling of a lot stuff that could not be previously secured.
That’s an entirely different issue. The domain validation process was followed to the letter and by definition of the Baseline Requirements, that means it was not someone who should not be able to obtain it (even if the site in question was misconfigured or hacked). The subscriber (that is, the person who actually obtained the certificate in question) is free to revoke it at any time using the certificate’s private key or their account key, in a completely automated fashion. However, as Josh explained, verifying that the person requesting this manual revocation is tricky. The BRs don’t really elaborate on how to handle these cases, so most CAs probably wouldn’t revoke in this case (see for example the recent CloudFlare/Comodo discussion on mozilla.dev.security.policy).
That’s not to say that if someone figures out a way to do revocation safely across account keys, without opening up a DoS vector, it won’t be added to ACME and eventually be supported, but revocation is still supported (and free) for pretty much every other use-case out there, and these cases are quite rare.
Just because your favourite SSL provider turned to crap, doesn’t mean the next best thing has to bend to your wishes.
I would like a detailed analysis about how verifying the root domain is enough to issue certs for every name under it. That claim and request got thrown out there so willy-nilly, I doubt that much thought has gone into it.
Similarily, you dismiss the huge discussion about cert lifetimes like it never happened and claim that your personal view is the only authoritative one. Then you try to validate your claim by calling the discussion an echo chamber that is most likely wrong just because… you said so.
if you ask me, we could abolish CAs (at least for DV) as a whole and upgrade to DANE/TLSA. it's simpler (no OSCP and all the stuff), safer (no anyone can everything), and easier for users (they dont have to do annoying validations with the CA, but just change it in the DNS) and a lot more direct (HTTP validation can go wrong with a wrongly configured server, allowing others to get certs for domains they shouldnt, while the Uploading of DS Records needs a one-time work with the registrar and they have a firmer grasp on who controls the domain (even if the real life identity isnt always established)).
where do you have that from?
the revocation fee is 10 usd per cert https://www.startssl.com/Support?v=25#72[quote="motoko, post:10, topic:22241"]
I have gone on record supporting an option for 1 year certificates, but not as a default.
[/quote]
This is something I can agree with[quote="motoko, post:10, topic:22241"]
Well, except for the $30 per certificate revocation fee
[/quote]
you need to update your sources, see above
well at least for a DNS verification it can be quite surely be assumed that the person has control to the subdomains either.
and it could also be possible to set a TXT record that says that subdomains are valid for this and that account key would make automated issuance a lot easier.
That's not really the full story. First of all, there's a reason a number of browser vendors implemented and shipped DANE and later rolled those changes back. Second, DNSSEC is a key escrow scheme, and for the most popular TLDs, you'd effectively hand over control to a single organization under U.S. control, so I don't see how everyone's suddenly supposed to be safer because of that. Unlike the CA system, you also have zero recourse in case they engage in what we would call mis-issuance in the Web PKI. Are you going to distrust .com? What would that even look like? It's also quite a complex thing to operate, so most people would go with Cloudflare (and maybe a handful other services) ... which kind of goes against the whole decentralization argument.
I'm not completely opposed to all things DNSSEC - I think it might be useful as a defense-in-depth mechanism for domain validation, or maybe even a requirement for high-risk domains or something like that. But please, no more than that, and if it never picks up any speed, I'm fine with that too.
(Anyhow, this is quite off-topic, I'll split this thread starting with this post if anyone wants to discuss this further - it would be a bit messy to start with the post I'm replying to as it's a reply to a number of other things as well.)
Before WoSign bought them, StartSSL charged $30 per revocation for all no-cost certificates. This fee was waived under certain circumstances for certificates issued to accounts that had paid for a higher level of authorization. I am glad to see they have reduced the fee. I suspect that many people are still operating under the higher number as this fee isn't widely advertised since it would harm the image of the offering as completely free.
My number is accurate as to the time period I referenced.
That doesn't sound like a bad idea, although it's really up to LE if they want to add that complication in. The more complex the rules, the more likely there is to be a bug that can cause issuance problems.
DNS is a hierarchical system where entities can delegate control to other entities. That means they technically have control over the whole domain, but as soon as they delegate a subdomain, they willfully pass along control over that subdomain to someone else and I'm not sure they should still have a say over what happens in that subdomain.
As long as control is delegated, they still have the ultimate control, of course, but the authority lies somewhere else by agreement.
So I wouldn't decide about this walking-up issue so willy-nilly.
The current dns-01 setup allows you to place a CNAME for all challenges to a central place once and never worry about it again.
This is a VERY, VERY long bow to draw. In any case, I'm not asking for the individual subdomain validations to be withdrawn, but allow root validations to be authoritative for the entire domain as well.
Why even open that can of worms? You want a name in a cert, prove control over that name. It’s as simple as it can be. I think these compromises were made in other places because everything was a manual process there. LE is different, so these sorts of compromises don’t have to be made.
With dns-01 validation you can CNAME the challenge record anywhere you want anyway, so it’s flexible enough to behave in a similar way.
I guess I will step in to defend DANE here in principle at least. Unlike CAs, which the vast majority of end users and even many systems administrators are ignorant of, people do seem to have noticed the existence of the TLDs. Because the ccTLDs re-use international codes also used elsewhere (except for in my home country and for that I apologise) the more cosmopolitan user even correctly associates the .de TLD with Germany, or the .ca TLD with Canada.
This means that whereas it’s completely unrealistic to expect users to make any sort of judgement at all about a particular CA Issuer, it’s not out of the question for even not-so sophisticated users to begin to associate, for example, the poorly run .com TLD with scams and shady businesses. Under DANE that correlation actually means something and the TLD registrar can take action to either improve their reputation or disregard it altogether for a cash grab. The reputations of the ccTLDs would be inevitably, and correctly in my view, tangled with the reputations of the country they belong to.
From a conduct point of view, I’ll contrast the root DNSSEC ceremonies (fully documented, with participation from parties around the globe) with the usual practices of Certificate Authorities, whether that’s WoSign or Symantec, everything done in secret by employees, strange occurrences are waved away as unimportant even when it later turns out something awful happened… these are not practices that engender the maximum trust.