In my view, no, that’s not what I read from it.
Out of curiosity, what did you get out of this thread regarding wildcard and longer lifetimes?
Out of this thread I got a general … Let’s Encrypt is based on a different model to other providers, copying or trying to emulate a CA that has problems isn’t a route Let’s Encrypt is likely to be going …
although all of the comments have been from various independent people and no official Let’s Encrypt response.
It’s a different model, for sure, but that doesn’t mean they shouldn’t endeavor to support more unique use-cases. As history has shown in many things, one-size-fits-all solutions rarely actually fit all.
I’d agree. Equally I’d say starting a thread with “Bringing up ‘your company’ to match ‘some other company’” is likely to start more of a negative battle than a constructive debate towards what peoples actual requirements are 
2 Likes
It’s perhaps unfortunate wording, but I’d disagree that comparing one free CA’s offerings to the other big free CA’s offerings–which is shortly going out of business–should necessarily spark a negative battle.
I’d be perfectly content with a forced donation to get wildcard out of LE in line with StartSSL’s pricing model.
I don’t know about the US, but in most countries a “forced donation” is not only bad news for actually delivering on the charity’s purpose (it moves the focus to revenue generation, that’s not a charity any more) but also interferes with charitable tax status. If your “charity” offers me a $10 product if I “donate” $10 then it’s obviously a regular business just using charitable status to hide income from taxes.
Right now you can donate to ISRG without using Let’s Encrypt, and you can (and many do) use Let’s Encrypt without donating to ISRG. Changing that in a big way means setting up a non-charity (as Mozilla did for example) to do all the non-charitable stuff and give its profits to the charity. But non-charity CAs already exist. If you want to give some money to a CA for a wildcard and some more money to ISRG, you can do that today.
Note: Just my personal view …
From my perspective it sparks a negative debate by the “bringing up” which can be read as the company you are approaching (LE in this case) is inferior - which in most cases starts to make people respond in a defensive and / or aggressive way.
If you want to get your “use case” supported, I think there is a much better chance of that by starting a new topic, describing your “use case” in detail (by which I don’t mean “I need a 3 year certificate” … rather “I have an xyz device that I can’t get certbot to run on, hence currently I have to do everything manually, I’d like help to get certs for the device in a way which means I don’t have to manually do this every 80 days”
If I take my case, I started using Let’s Encrypt a year ago. It wouldn’t work on lots of my servers / devices at all … so I worked with Let’s Encrypt, developed a client to do the job that was required and now all my systems are automated and work without issue. Did it have a few headaches and problems getting there, yes, and Let’s Encrypt helped support me though those issues. The cost to me was a little time, effort, and understanding (rather than a donation or anything financial). It achieved everything I wanted within the first 90 days though, and saved me hitting the brick wall of longer certs, wildcards etc.
It’s worth taking the time and effort to see if there is a way that both sides can work together, to achieve a suitable outcome. And that rarely works if one side, or the other, is inflexible. There are various ways around all the issues ( including wildcard certs, longer lifetimes etc) if approached in the right way.
As I said at the top - it’s just my personal view and experience. I’m not in any way linked to Let’s Encrypt, and usually stay well clear are what are potentially flame threads … so I’ll probably step away from this thread as well
Typical use-cases for wildcard certs and longer lifetimes have been mentioned repeatedly in other threads, usually with the end result of “it’s something we’ll think about”.
I believe the purpose of that thread was to attempt to spur a greater sense of urgency since the alternative is going away.
Regarding “forced donations”, call it whatever you like but at the end of the day it’s a charge for a service and I don’t intend to pretend it isn’t. All I’m saying is that I’d be willing to pay a reasonable fee, ideally with the pricing model of StartSSL in which you pay once and then your account can issue unlimited wildcard certificates for domains you’ve validated.
Ok, so while people have gone off topic a little, I’ll bring it back onto topic with the exact, thought out reasoning.
Yes, I do believe the LE offering is inferior to the validation required by StartSSL. The limiting factor is that you need to validate EVERY HOST you wish to partake in an LE certificate. This by its very nature is limiting.
I have a number of systems that are not accessible to the wide open internet, nor do they have DNS records available to the big bad internet. They DO have DNS entries for local network operations. I cannot use an LE certificate on any of these type of systems without both advertising the existence of an internal system to the internet via DNS (a TXT record), or having this host reachable from the internet to allow LE to validate that it exists.
StartSSL only requires the root domain to be validated. Once this is done, you can generate certificates for any subdomain under that domain. Hence if you own and control the root domain, by the very nature of DNS, you own and control all subdomains.
StartSSL: 1, LE: 0
StartSSL Class 1 certs are now 3 year. While I would prefer 1 year (with an option for 3 vs the default), this is much more useful than 90 days. I’m not going to revamp the million reasons why here - as this has already been covered to death and there is a million valid reasons as to why a 1 year expiry is valid vs 90 days.
The argument of “but infosec guys say shorter expiry is better” is only partially valid - because most of those guys have never had to actually administer stuff on any large scale or over many years (some domains I own would now be allowed to drink and vote!). In fact, I’ve owned domains longer than a lot of these guys have had careers. I’ll admit that I don’t know everything, but neither do these guys…
End result though, StartSSL: 2, LE: 0
So, to make LE more useful - as per my requests in my very first post - most of the validation problems evaporate if LE would allow the root domain validation to be authoritative for subdomains. This would instantly solve 90% of implementation problems. It would allow workarounds to the 90 day lifetime that would not require a redesign of basic security to use LE on anything ‘off net’.
Now before the rants start about “well you’re not force to use LE” etc - I acknowledge that LE’s goals are good - but implementation problems seem to be a massive hindrance in achieving those goals. I would rather improve LE than just ignore its existence.
If you're looking at single domain (non-wildcard), that's way more than normal 1 year ones. If you're talking wildcard, I've not seen them that low. Typically wildcard certs are useful for tons of subdomains, and are a better value than buying multiple single-domain certs.
I haven't seen anyone make an official statement or even anyone with the project make a personal statement to that effect. I don't even think I've ever seen anyone say that it fits every use case. There are many cases where it won't work or will require customization to the process to make it work. However, it works well for many cases and in many situations where traditional CAs have underserved audiences due to cost.
That particular situation is perfect for a private CA. Where you have only internally-accessible machines that you don't want advertised to the public, use a private CA since you can control what accesses those systems.
If you like StartSSL, you can always re-add trust for their CA on your internal systems if you want to keep doing what you're doing.
This is the part that people still haven't latched onto the logic for. Just because its not available to the internet doesn't mean that its not used by a small subset of user controlled systems.
Think use cases like wireless hotspot systems. Internal ordering systems for venues etc etc etc.
Just because its not available on the internet doesn't mean that its only used by a small, controlled group of clients.
1 Like
Either way, you'll need to prove you can manage that subdomain to the authority, and that means some kind of public proof and in many cases, display in certificate transparency logs. LE has decided for right now to have the requestor prove for the specific name you want on the certificate. Maybe they'll change that policy later on, but it's their right to keep that requirement to ensure that mis-issuing certificates doesn't happen. Open validation has caused issuance problems before (see some of the stuff around WoSign's issuance issues), so I don't blame them for being cautious.
2 Likes
Correct - which is why most problems in my use cases would go away if you can validate the root domain.
Logically, you must own every subdomain under the root if you can validate the root - which from all I have read meets the validation requirements for DV. StartSSL didn’t get into any problems for this - so I’d rather the different issues not be confused with each other. If you own mydomain.com, by the very nature of DNS, you also own www.mydomain.com - and mail.mydomain.com and hostx.mydomain.com etc etc.
I’m not saying this should replace the existing validations, but extending both dns-01 and http-01 to validate the root domain and then allow subdomain certificates to be issued would fix 90% of my problems.
90 day expiry (while not my preferred length) could be worked around if the validation was at the root level.
There seems to be a lot of anger over a serious disconnect here: The idea that because Let’s Encrypt is the only free CA left, it has to be the one and only free CA forever. I know that “if you don’t like it, go start your own” is rarely a good argument, but in this case, the market exists for multiple free providers with different tooling and different amounts of flexibility in their processes.
The founders of Let’s Encrypt have a very specific vision of a very specific kind of validation behind their issuance, and haven’t shown any sign that they’re willing to become more flexible despite thousands of posts on the topic, therefore it stands to reason that continuing to post about it is a waste of time. For better or for worse, they appear to have no intention to change the policy no matter how many posts you make.
They got in trouble for a bad issuance for allowing someone who validated a sub to issue to the root domain. Software issue, and probably alone wouldn't have been as huge of an issue on its own, but it shows that the direction can be done incorrectly.
If anything, I'd only allow it for dns-01. There are several situations where the person running a website for the root may not have authorization for claiming ownership of subdomain names. That would add considerable complexity, though.
1 Like
StartSSL didn't allow you to validate a subdomain - it was always root or nothing. I'm not sure where your info came from this - but from years of using StartSSL, it seems incorrect.
The other valid options that were non-root were the following email addresses:
hostmaster@domain.com
postmaster@domain.com
There was one more email address that I can't recall off the top of my head. There was never a HTTP method that could validate a domain from anywhere that wasn't at the root level.
I'll just get into new things that were brought up, I feel the rest was already covered and/or is a matter of opinion.
I should point out that both Let's Encrypt and StartSSL announce the existance of all your hostnames to the world via Certificate Transparency. That's a mechanism that will become mandatory for all CAs within the next year, but both Let's Encrypt and StartSSL support it already. The only way to get around that would be to use wildcards, which prevent you from knowing the exact hostname.
This was definitely possible with StartAPI back when it was available (which wasn't long, since it turned out to be quite insecure ...). Same with HTTP validation.
1 Like
CRCinAU, StartCom offered an API to sort-of compete with ACME, for a brief period, before they shut it down. Along with many other grievous security problems it let you validate control of example.com based on proving the ability to serve up web pages from a TCP port of your choosing on www.example.com
Needless to say this was not thought to be sufficient “validation” although technically it was possible to squint at the BRs and argue that doing this wasn’t prohibited by those.
1 Like
StartAPI still works… I used it the other day?