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

Let's Encrypt does exactly the right thing, which is to email you if a certificate is expiring without being renewed. Pretty much the behaviour you'd want from any CA, no?



That's a great start.

But in a non-technical organisation, who should those messages go to?

Often the initial LetsEncrypt setup will be handled, correctly, by some IT staff. Then it might break several months or years later for some odd reason.

The organisational challenge is to get the message through to someone who understands it and will act on it.


Yes, and: fix bugs so the setup doesn’t break. I’m constantly babysitting LetsEncrypt. It’s always failing in some stupid way, and all it can go is Email me with: “Ive been silently failing for the last couple of months and now your certificate is going to expire if you don’t drop everything and comb through my logs now LOL!”

This time the problem was LE all of a sudden decided to start storing my certificate in a directory called mydomain.com-0001 instead of mydomain.com, breaking the rest of the setup that relies on things being in the right directory. Automation is only useful when the software behaves predictably and consistently.


Comforting to know I'm not the only one who constantly has random problems with Let's Encrypt. You're on point about the silently failing bit too.


LetsEncrypt issues for 3 months by default and then tries to renew after 2 months.

So if renewal fails you should have ~30 days to fix it.

But this does work best if your tools try the 2-month renewal. (I'm looking at you, wpengine!)


Which client are you using? Certbot?


> The organisational challenge is to get the message through to someone who understands it and will act on it.

Yes, and to keep a very infrequently used channel working and up-to-date.


This is why letsencrypt very sensibly creates short-lived certificates, meaning that the channel is not infrequently used.


The channel only needs to be used when the automated process breaks.


Oh right - yeah, that sucks. Rarely used processes often break.

Hence efforts like https://tools.ietf.org/html/rfc8701 - designed to make sure extensibility options don't get messed up.


It doesn't eliminate the need for monitoring.

I'm looking for a program that is going to connect to all my SSL sites, and report back a problem if the cert is within 30 days of expiration. It is easy enough to write a client that will fail after the cert has expired, but I want one that will warn me ahead of time. And I don't want to mess with the system clock or something like that.

It shouldn't be a big program, I may just write it myself.


Nagios can do that (and you could borrow from its check_http)

  define command {
    command_name                    check_certificate
    command_line                    $USER1$/check_http -H $ARG1$ -p $ARG2$ -4 -S -C 21 -t 20 --sni
  }
A bigger challenge is getting a complete list of your https websites, and an even bigger one is finding and monitoring all those non-https certificates, eg payment gateway certificates.


https://sslping.com

is totally free, superfast and checks your TLS settings too (it's my baby)


https://letsmonitor.org/

Also my employer (well, until the end of this week) Kynd does this as part of its broader "Check cyber-security stuff" offering for non-technical people. https://www.kynd.io/


Hi, I'm a co-founder of Amixr and we've developed curler.amixr.io, which monitors a website and delivers email notifications for free and also has an integration with our flagship product Alert Mixer


Depending on your use case, environment, etc there are existing tools like Monit that can do this for free. Or paid services like Uptime Robot and StatusCake.


updown.io https://updown.io/ has a pretty generous free tier and (in addition to checking if your service is up) sends you a warning when a cert is expiring within 14 days


For sure it's not a letsencrypt problem.

But as a person who rolls LE certs across a very non-happy-path environment (many SAN domains, edge nodes which are geo-balanced).

I have a lot of issues automating this process, right now I have a HTTPd which reverse proxies the .well-known back to a central place where I run certbot and then I push out the cert to the nodes, however, sometimes one of our SAN domains will need to be removed and the whole universe comes crashing down.

DNS-01 Challenge is "nice" (although, doesn't feel super well supported); but requires domains registered with some kind of DNS server that accepts API's to change records, so Amazon route53- but it's exceptionally hard to roll your own DNS in this case. :\


Two tricks that might help you:

1. HTTP-01 challenges have a "correct" answer for a given Let's Encrypt account which depends only on the challenge (ie the part in the HTTP GET request) and on knowing which account you want to use.

Silently Certbot creates you an account, with a private authentication key and so on, for the Let's Encrypt service. When it gives you a file to prove control by placing it in /.well-known/acme-challenge/ the content of the file is always the same as the filename, plus a suffix that depends on your key.

So long as you use the same account you can thus bake this suffix into the web server, essentially causing it to answer any request from anybody: "Hey, who is allowed to issue for somename.example ?" "dijit is allowed to do that". Bad guys can't use this because they don't know your private account key, but for you now magically everything is authorised, since when it is asked your server will answer "dijit is allowed to do that" to any question it's asked.

2. DNS-01 can be redirected using CNAME. Add a CNAME, once, manually if necessary, to redirect the DNS-01 checks to a DNS server you've set up for this specific purpose.


Besides the multiple commercial DNS providers which certbot has plugins available for there is also a dns plug-in supporting rfc2316 updates. This means it can be integrated with a large number of self-hosted DNS servers. Bind, powerdns and Microsoft DNS are just some of the servers with rfc2316 DNS update support.




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

Search: