Which is what drives the automation requirement in order to be used in an ongoing practical way in production environments.
but well as I also said often enough when you can just upload your certs via some more or less impractical web interface, automation is useless
Automation isnât useless.
1 Like
it isnt useless in general but it gets useless if it has no interface to do something, if the client cant upload into that obnoxious webinterface (which might even be riddled with a captca, which is since recaptcha v2 not really a nuisance anymore) of a random hoster then it the whole concept fails for that use case and manual gets required.
1 Like
For shared hosting we need integrations, right.
and thereâs the problem, will the hosters even think about doing the effort? as the general conensus is ânever change a running systemâ I dont think so.
and thatâs why I think it should be OPTIONAL in MANUAL MODE ONLY to get certs that are longer I mean this isnt the DNSSec Root Key SIgning CeremonyâŚ
2 Likes
Yes, I think so. Once it's published as an official RFC.
well even if acme gets an RFC I dont think everyone will implement it I mean Webclient (webdav in Windows explorer STILL doesnt support SNI (status win 8.1 at the very least)âŚ
by the way it was added in TWO THOUSAND AND THREE (2003) via RFC 3546âŚ
2 Likes
Could you elaborate on the novelty of ACME compared to, say, CMP?
Maybe not every hoster wants to implement it but many i think will do at some point (it's not rocket science). Hosting is a competitive market, those who still want to sell DV certs or are lazy then have to explain to their customers why they charge them for something that competitors provide for free and fully automated. So if your hoster is crap, go somewhere else.
As long as LE works flawlessly for some time confidence will build up. And nobody is stopping a hoster to offer a "guaranted stable 5 star super secure blala" cert from a commercial CA in addition to a basic "we can't guarantee for anything" service based on LE.
the host might once control panels do.. alot of shared hosts use web hosting control panels i.e. plesk, interworx, directadmin and cpanel
I know there's a LE client for plesk being worked on by 3rd party and cpanel folks are interested and looking on with feature request at https://features.cpanel.net/topic/provide-support-for-lets-encrypt-automated-certificate-management-ssl which shows demand for LE integration into cpanel control panel
not every host has support for custom SSL certs, because they wanna make money with the ones they sellâŚ
1 Like
True but i am pretty confident that once Letsencrypt is out publicly, clever folks will find a work around or post how to get LE to work with their relevant web host control panelsâ server environments.
Then again it only takes 1 or 2 control panel folks to implement Letsencrypt to motivate other control panel developers to follow suit or be left behind. Then it only takes a few web hosts to offer up that control panelâs LE implementation as a value added service feature, then other web hosts might be motivated to do the same. Making money is one thing, but retaining your web hosting clients in the face of competition is another priority 
With that said with all 3rd party client implementations once of my concerns is defragmentation in that space similar to Android development from various phone manufacturers Preventing Letsencrypt 3rd party clients going the Android way?
I'm surprised such a vague comment has attracted so many replies. Upon request for further clarification as to what @NOYB actually means (especially @Kryten), none has been forthcoming.
Please provide specific pointers to where these "crucial community concerns" lie and the "dismissive stance" LE has taken as I'm struggling to find them by myself.
3 Likes
Ah, no. Usually, the same software source code can be easily compiled for different CPU architectures (unless the software depends upon some architecture-specific feature, which would be unusual). Especially within GNU/Linux. So, it is typically much easier to compile a given piece of software for a different architecture than it is to port that piece of software to a whole new operating system.
Yes, and automation can fail. We have several certs and do not trust automation or emails notifications to let me know when I need to renew. Weâve been happy with this service to alert us using SMS:
So a year on, concerns are still exactly the same, and nothing has changed.
Does this mean LE is to be relegated to a niche market of people going âEh, just let a script handle my certsâ?
It almost makes me cringe as much as installation instructions that are given as:
wget -O - http://random.web.url.com/install-script | bash
Urgh.
No, youâre free to write your own client. You keep smearing LE just because you donât get what you want. LE is first and foremost an API you can use and not the certbot client. This âwget | bashâ comparison is completely ridiculous. In fact, LE is the complete opposite, because right now itâs more secure and you want to have it less secure to meet your use case that doesnât quite fit the LE model.
1 Like
You keep using these words âmore secureâ and âmore trustworthyâ - but I donât think they mean what you think they do.
There is NOTHING that makes a different method of validation less secure. It doesnât degrade the encryption, it doesnât change the ciphers, it doesnât change the legitimacy of the cert. It doesnât magically change the security of a cert when issued for 180 days vs 90 days.
What we ARE talking about is validation policy.
Donât try to confuse the difference. You do it again, and again, and again, and its flat out wrong.
Now you have to prove ownership for every exact name. With your proposal, you donât. Tell me how that is not less secure in the sense that only the proper authority of a name can get a cert.
(Of course Iâm not talking about ciphers and encryption, duh!)