Short certificate period - no useable on multi server scenario

was referring to Please support wildcard certificates - #28 by eva2000 and Please support wildcard certificates - #57 by eva2000

but yes alphassl wildcard is another option too although i only know comodo/gogetssl and symantec that offer RSA and ECC 256bit SSL certificates, not sure if alphassl supports ECC 256bit :slight_smile:

well I dont know much bout ECC but how’s server and client support (not just HTTP/S server)

Just FYI you do not need a certificate for every domain. You can include multiple domains into one cert:

1 Like

The ACME can protocol goal is to automate the process.

Google "cronjob".

OCSP has nothing to do with the certificate lifespan. OCSP is to check if a certificate is still valid, and you can staple it, ie, include a proof that the certificate has not been revoked, so clients do not need to do the OCSP check on their own, adding latency to the connection establishment.

If someone cracks the sha1 of the certificate (ie manages to produce another evil cert with the same sha1), it will be able to supplant your webserver, and the OCSP will still say the sha1 is a valid, trusted cert.

Also most clients do not attempt to do OCSP validation. If OCSP is stapled, they check it. But if it’s not, they just trust the certification expiration date. Only big players make the revocation of some certs flow into the browsers via updates and then got some real revocation abilities.

well if the stapled thing is checked it kills the point of the stapling…

also you do know that sha1 certs arent issued anymore that much and LE doesnt even plan to issue SHA1 certs as what I read at mozilla where they responded with some info

In fact is more reliable to force people to automate things by being a frequent task, than something you do every one year, that nobody knows how to put in prod. Even big players have forgotten to update a certificate in time, so I think is good to make this routine rather than an exceptional process.

2 Likes

but if I cannot automate ity you know LE’s compatibility is still way too low and the apache and nginx options are (as per docs) on alpha and very experimental respectively, and I wouldnt use software that labels itself as alpha or very experimental for automation on more-or-less important “servers”…

2 Likes

Then either wait or help making it more stable. But please stop, we’re running in circles.

2 Likes

well providing optional help for manual users would also be nice.

2 Likes

But manual mode isn’t the goal of LE.

1 Like

but it also is needed for all the stuff that cannot be automated.

2 Likes

i hope that people who need ssl HAVE TO return to write some batch code.

(fun fact: human interaction is the only way we will not kill by SkyNET)

there are envorinments who CANNOT RUN batch or SSH code on their severs, shared hosting, anyone?

1 Like

can upload an SSL and a a file = can upload the .well-know/acme-challenge/... and LE's SSL.

well carrying out the challenge is one thing but why should we need to run batch code?

a nice gui (especially a webgui that doesnt need to be installed anywhere) is in my opinion the best approach.

1 Like

Let’s Encrypt is supposed to be as automatic as possible. So I would think that you will be able to create a list of all your domains and subdomains in a file, then specify that filename to the Let’s Encrypt installation tool, once only. I can’t think of any reason why this functionality can’t be supported easily. If this would be available to you, would your complaint about short cert lifetime go away? I believe the short lifetime is very important to the success of this project. But the automatic tool functionality is completely under our control.

2 Likes

This is somehow nonsensical. If I manage to compromise a server and am able to retrieve the key pair to the certificate, I'm also able to wait for the certificate to be renewed.

2 Likes

@kenny: Who says you compromised the server? There are hundreds of certificates and keys of many kinds (GPG, SSH, SSL) floating around various “cloud” VCS hosts (i.e. GitHub, Bitbucket, etc.). The quicker those are invalidated the better.

To have an advantage of short-lived certificates, you assume that renewed certificates will not be committed to these VCS hosts again. I'd question your assumption.