I like this way of thinking, but a crl gets longer when you have a longer cert time since each cert needs to stay longer in there…
Having a short lifetime doesn’t have anything to do with how long it takes to crack a certificate - with enough computing power you could certainly crack it in less than 60 days or 90 days or whatever.
The short lifetime helps if the certificate is compromised: if it’s compromised, but doesn’t expire for 2 years, then damage could be done any time in that 2 year period. If it expires in 60 days, then the bad guys are going to have to act faster.
but at the very least as soon as the compromise is known then it will be revoked…
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
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:
The ACME can protocol goal is to automate the process.
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.
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”…
Then either wait or help making it more stable. But please stop, we’re running in circles.
well providing optional help for manual users would also be nice.
But manual mode isn’t the goal of LE.
but it also is needed for all the stuff that cannot be automated.
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?
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.
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.