Hacker News new | past | comments | ask | show | jobs | submit login

Ehhhh, so I get why you made this, but at the same time, LetsEncrypt intentionally chose 90 days for the duration of the certs. Presumably because renewing a cert is a positive confirmation that you still retain ownership. You actively performed an action that declared: hey I still retain control of this and it hasn't been compromised. (as opposed to other states your cert could be in -- abandoned, compromised, password forgotten and you were too lazy to get the cert revoked-- trust me, engineers made cron because we were lazy especially when it comes to mundane things).

This is around-about way of saying that 90 days was a well-thought out duration to issue a cert and the process of renewing it manually is there as a positive (rather than passive) confirmation you retain control. These guys are doing a public service, on par with archive.org and the EFF. I'm not sure, but even though I've been using cron since before I was a teenager, I'm not throwing that entry in.

Edit: Whoops, so I was half-wrong, mea culpa. https://letsencrypt.org/2015/11/09/why-90-days.html Part 1 addresses the security issue I brought up, and part 2 endorses automation. My mistake.




Actually, no: the default 90-day certificate lifetime was chosen such that it wouldn't be too inconvenient for manual renewal if necessary, but was intended to encourage automatic renewal: https://letsencrypt.org/2015/11/09/why-90-days.html


Let's Encrypt gives encouraging automation as a reason why they choose 90 days:

They encourage automation, which is absolutely essential for ease-of-use. If we’re going to move the entire Web to HTTPS, we can’t continue to expect system administrators to manually handle renewals. Once issuance and renewal are automated, shorter lifetimes won’t be any less convenience than longer ones.

https://letsencrypt.org/2015/11/09/why-90-days.html


> If we’re going to move the entire Web to HTTPS ...

Doesn't support IIS at all


There's been some efforts to support IIS, including a client for use with powershell.

[1] https://github.com/ebekker/ACMESharp


Most viable product.

IIS is ~12% of the market, and they were able to catch 78% already.

They've always said, they're working on a basic version to get traction, and improving it from there.



Hah thanks, I knew something felt wrong about what I wrote. :P


I think `Most` was quite adequate given the achievement though.


   > Wants secure webserver
   > Uses IIS


That philosophy is perplexing because system admins already have to manually handle things like software upgrades. Unlike SSL renewals, upgrades usually occur to an arbitrary frequency yet admins seem to be able to cope.

I'd also contend that 90 day expiry makes end-users less sensitive to certificate change notifications; at present if a website renews its cert after a year I receive a pop-up and I pay attention. Receiving one every 60 days will just condition people to start ignoring cert changes, whether valid or not.


What? No browser displays a notification when a website changes its cert. It doesn't even show you a notification if it changes its key, that's the whole point of key pinning: https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn... (A pin failure results in a non-bypassable HTTPS error: https://projects.dm.id.lv/Public-Key-Pins_test )


The most popular way to get that is: https://addons.mozilla.org/en-US/firefox/addon/certificate-p...

I personally no longer use it because of all the noise, even before lets encrypt.


The end users should ideally not be prompted when they see a certificate renewed by the same CA. It should also ideally be a /renewal/ of the old one, and not an entirely new private key generated each time as well. Of course everything could be tuneable.

I believe these are sane defaults.

* Prompt on CA change? (Default Yes) * Prompt on private key change? (Default No IF the cached certificate is on the old CA's revocation list.) * Prompt on CA renewal? (Default No)


> It should also ideally be a /renewal/ of the old one, and not an entirely new private key generated each time as well

sure? A new key provides quite a bit of security benefits because even when the key got loose without you noticing, three months later, it won't be usable any more when the new cert is made for a new key.


There's a browser that gives certificate change notifications by default?


Users should be able to safely ignore certificate changes. No one should need to install Certificate Patrol to have a safe experience.

Of course, if the certificate changes to an untrusted one, the browser should flag it -- and if the server specifies HSTS, then the browser should block the user from clicking through anyway (increasing the pressure to make sure the cert is always trusted and unexpired).


How do you decide whether the new certificate is genuine, other than it being issued by a valid CA?


Maybe the message could be hidden if the new cert was signed by the old one?


> LetsEncrypt intentionally chose 90 days for the duration of the certs. Presumably because renewing a cert is a positive confirmation that you still retain ownership.

LetsEncrypt does domain validation only so there is zero check who owns the server. So no, that makes no sense. You can already crontab the official client anyways.


>hey I still retain control of this and it hasn't been compromised.

For the most part certificates have never provided this guarantee. What they do guarantee is that A) the entity you're communicating with is in control of the private key and signed certificate that you expect B) your communication with that entity is secure from a man in the middle attack. And mostly B if you're visiting the site for the first time.


I get your point, but what sysadmin doesn't want to script everything?


You can't script everything. Otherwise, we'd all be at the beach drinking mojitos checking Slack to see how the bots are doing.

I mean, that's the goal. But we're a ways off.


We are all at the beach and were just wondering where you were!





Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: