Show HN: Never have an SSL certificate expire again | Hacker News Reader

Show HN: Never have an SSL certificate expire again

haveibeenexpired.com

40 pointsadrukh71 comments

> We don't do email notifications!

Weird choice. SSL certificates are generally not urgent enough that I need to act right away, so any IM notification will be forgotten before I can act on it. Furthermore email is the most widely supported communication system as opposed to proprietary chat systems.

Email is expensive, require extensive monitoring, bounce checking, extra storage, opt-in verification. Webhooks are cheap and quick.

1 email is $0.0001 on AWS SES 1 webhook is ~$0.00000083 assuming 512mb for 100ms.

You are totally correct! But another way in which email is 'expensive' is troubleshooting deliverability issues, handling bounces, unsubscribes, landing in the 'promotions' tab of your gmail inbox, etc.

Webhooks are... easier to consume.

This is intentional (although may change in the future), for one main reason - I believe that email is personal, and webhooks are a much better way to notify _teams_. Strongly believe that SSL expiration handling is a team effort!

Thanks for this feedback!

You speak as though mail groups were not invented several decades ago and don't see widespread use in pretty much every organization that uses email.

Sorry, wasn't clear - I want to get the minimal input from my users, and right now all I have is the google email.

Totally agree that to capture the audience that relies on email, asking for a mailing list for notifications is much better than notifying the personal email address I get via SSO.

Some current stats on this: 12.5% of the registered users have added a webhook of some sort to their account. This is the primary engagement metric for me, it's very low, but I want to find a way to drive it up before I give in to email :)

Other than mailing list and shared inboxes it also seems that every oncall system and enterprise chat tool has support for receiving email. Email is just the standard protocol, people can consume it however they want.

I agree with this.

And it's not only teams who would use this service, since it has a generous free tier.

If I hadn't built my own system, I'd definitely use this one, and receiving an email would be nice as a reminder which could hang around in the inbox until I have time to deal with it (if I'd had the need to, since it's all automated). I don't use Slack, nor Discord, but XMPP, and if I'd set up a Webhook handler, it would end up sending me an email and XMPP notifications.

I have a small custom SMTP server which serves as a "webhook" handler for me to get USGS Earthquake Notification Service (ENS) notifications as well as backup success notifications from my VPS provider, since they don't provide Webhooks. So I'm basically doing it the other way around.

Maybe offering it as an experimental "no guarantees" service would be useful for many of us and give the service provider a chance to learn how to send emails from their own servers in such a way that they actually reach their destination without getting flagged as spam.

I also found no information on what happens if the Webhook endpoint is not reachable.

I like the idea of this SSL expiry checking service and the site looks nice.

Thank you, this is quite insightful!

> I also found no information on what happens if the Webhook endpoint is not reachable.

When setting a webhook, the app checks it for validity (you get a nice 'hooray, it works!' message posted through the webhook). So if the webhook URL is bad, the app won't accept it. But once accepted, there is no retry policy if a specific notification fails. The failure will be logged internally for troubleshooting, but not presented to the user in any way right now.

"Companies we monitor: Hashicorp, Datadog, Auth0 and Github" or how to be deceptive in marketing material.

Bingo. Exactly what I thought when I saw this.

Of course these orgs have their own infra monitoring, but technically anybody can monitor them and then claim to do so.

Is this style of marketing legal in US? In the country I am in it is quite likely to be illegal due to being deceptive. In my country being technical correct doesn't help if misleading.

(If these companies signed up for the service then or course it would be legal to claim that.)

Logos are fine as long as you have an agreement in place, but you run afoul of a number of laws by using another companies logo without their approval. Although, it seems this happens all of the time with various companies.

As for myself I turn down every request for a logo, I like and use your product but I don't really care if you cut me a small break for using it.

I'm not sure whether this type of marketing being legal in the US is as relevant as is this type of marketing legal in Israel since it is an Israeli company.

Maybe it differs from company to company and country to country, but at least the company I work for would hesitate enormously before purchasing a service from a company which immediate appears to do something that is illegal in many countries.

This company (is there a company behind it, I couldn't find those details) markets to countries outside of Israel I assume.

:wave: I'm an Israeli citizen, and this app is basically mine. No company behind it.

I hear what you are saying about the credibility hit I'm taking with showing logos like this. Will think what to do about it!

Alright. I think you should remove those logos but I'm no business guy.. Either way I wish you good luck. Sorry if I sounded harsh.

:hugging_face:

I totally admit the tweak here! Of course these giants don't rely on my service, and have better tools. But hey, I do point out an upcoming glitch here and there - https://twitter.com/haveibeenexpir1/status/14475025605212405... for example.

Any reasonable person would read "Companies we monitor" as "Companies that pay for and rely on our services", if that's not your relationship with the companies, then it's just using deception, and probably also violating trademark

Thanks for this feedback!

I have now changed this to include only logos of companies with whom I am directly involved, who are actively using my service to monitor their SSL certificates, and who have agreed to have their logos appear on my landing page.

What might be interesting to be notified about is certificate issued but not deployed (i.e. in CT logs, but not presented by web server).

What's the compelling reason to use this over, say, Hardenize[1] or Oh Dear[2]?

[1]: https://www.hardenize.com/

[2]: https://ohdear.app/

That would be my exact use-case for a service like this: monitoring a domain I have pointing at localhost (and not only for expiry, but also for revocation). At least currently the demo check fails on trying on trying to establish a connection[0], although a valid certificate definitely exists[1].

[0]: https://www.haveibeenexpired.com/ssl?q=colasloth.com

[1]: https://crt.sh/?id=5909251719

Yeah, that won't fly on my app right now because I only want it to notify you about an SSL cert that is both being served by some publicly-reachable host AND is about to expire soon.

A cert that was issued, found on CT, and expires tomorrow? Who knows, if it isn't served by any host/LB, let it expire, right?

Well, just letting it expire would certainly halt local development at <dayjob> until renewing. The primary reason for this is that some integrations require TLS for callbacks, so we have a local reverse proxy serving everything with TLS enabled. Hence, it's just more pragmatic to run the dev environment with TLS enabled all the time: no need to modify configurations and reset the browser cache when moving between a TLS and non-TLS setup.

I do get emails from the CA reminding me to renew a month or so before expiry, and the certificate hasn't been revoked as of yet, but it'd be useful to be alerted regarding the latter, were it to happen.

I'll look into those, thanks for the heads-up!

Off the cuff answer - I want to be very focused on a specific use-case - a live cert that is about to expire. This allows me to be very greedy on the automatic addition of new hosts, without polluting you with notifications you don't care about.

I have a super hacky job for this personally on my personal infrastructure after acme.sh failed to renew too many times, which runs a bash script in a cron job to use openssl s_client, greps for the nonAfter field, passes it through python to parse the date into remaining days, then sends a message to my gotify setup.

I'll probably rewrite it as a single rust binary one of these days.

Sounds similar to my setup. I have a bash script which takes a list of TCP addresses (host:port ), contacts each one using openssl s_client, and uses the notAfter field to calculate how many days until expiration. I use the date command to parse the date that's returned from openssl and convert it to seconds.

The core of script is this snippet of bash, where $target is of the format host:port.

    cert_exp_date=$(echo | openssl s_client -connect "$target" 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f 2 | head -c 20 )
    if [ -n "${cert_exp_date}" ]; then
      cert_exp_date_seconds="$(date --date="${cert_exp_date}" +%s)"
      now_seconds="$(date +%s)"
      exp_days="$(( ( cert_exp_date_seconds - now_seconds ) / 86400 ))"
      echo "certificate_expiration_days,name=${name},target=${target} days=${exp_days}"

The script is executed as a Telegraf exec input so that the data can be fed into my general monitoring setup (InfluxDB and Grafana). I have a Grafana alert for each host.

If you're already using Python, there is a very good module for this:

https://pypi.org/project/sslyze/

Can use it from the command line too:

  python -m sslyze news.ycombinator.com

Why re-invent the wheel when there are already well-tested things out there?

* https://github.com/matteocorti/check_ssl_cert

* https://www.monitoring-plugins.org/doc/man/check_http.html

* https://exchange.nagios.org/directory/Plugins/Network-Protoc...

Why not? It's for my home lab to play around and gives me a chance to mess around with some lower level TLS stuff.

(Also acme.sh has soured me a bit on multi-thousand line shell scripts)

I've been fairly satisfied with dehydrated.io.

I hand-rolled some scripts a while back to do this, and example.com/feature was on a different machine than feature.com...still had some downtime when it wasn't replaced along with the rest.

So, weird product fit, I think? You have to be small enough not to have a real enterprise grade visibility platform (like ThousandEyes or whatever) which will already have that capability, but also have enough legacy not to be fully automated already (e.g. LetsEncrypt, ZeroSSL, CSP integrated certificate management).

Automating with LetsEncrypt doesn't mean your certificates don't expire. It just means the failure case looks different. Typically something gets messed up with the server configuration such that the auto renew doesn't run or it doesn't run successfully.

OK, sure, I guess the "we have automation but it's not something we're checking for function" crowd can benefit.

And not quite together enough to have a prometheus and simple blackbox exporter set up.

Wouldn't it be easier to just put it in your existing monitoring system?

* https://github.com/matteocorti/check_ssl_cert

* https://www.monitoring-plugins.org/doc/man/check_http.html

* https://exchange.nagios.org/directory/Plugins/Network-Protoc...

Or with Prometheus: https://github.com/prometheus/blackbox_exporter

https endpoints will include the probe_ssl_earliest_cert_expiry metric, which is the expiration in UNIX epoch seconds. Use with the builtin time() function.

Absolutely!

But... my app automatically finds new relevant hosts and adds them to the monitoring cycles, needing 0 intervention after you tell it which domains interest you. Not saying it's everyone's need, but I'm here for those who need just this :)

Right. And you don't have do depend on yet another external service for a simple task.

From what I can tell this service will only check website certificates.

Can anyone recommend a similar service that doesn't have this limitation, ie one that can check certificates on SMTP, IMAP, and other protocols that aren't HTTPS?

Ah, very nice! Not sure it'll work, but you can specify any port for a website you want to check manually. See if https://www.haveibeenexpired.com/ssl/app.srsc.ru:8443 (replace the host name and port with what you need) works for you?

The automated monitoring (once you sign up and add domains/hosts) only checks HTTPS, so no dice there...

No, sorry - that doesn't work. Results in "Parse Error: Expected HTTP/".

My policy is that its best to automate renewal to monthly or so. If you ever see a cert within 6 months of expiry something has gone wrong. Dont leave to the last minute.

This is a tough market to compete in. Unfortunately the pricing here isn't competitive with existing feature-full and mature services. For instance, updown.io will monitor 50 websites every 5 minutes for under the monthly price, and that includes uptime and certificate monitoring with email, slack, and SMS notifications.

To succeed it seems the product either needs to revise its pricing or add more features to justify the cost.

Totally fair!

In a market that is very saturated with feature-rich services, I want to do something narrow, and address a specific need. It makes it easier for me to rely on certificate transparency, as I'm adding new hosts automatically, without risking noisy notifications. I wouldn't want an uptime service to glob whatever hosts it finds in my domain just to tell me they go down, or don't respond to HTTP. But an SSL cert is either served, and has an upcoming expiration date, or isn't served - in which case I'll never alert about it :)

I use certdays for it:

https://github.com/no-gravity/certdays

Works with any monitoring system. For example if you want your tests to fail if the cert for a domain is valid for less that 14 days, you put this in your tests:

certdays.sh somedomain.com 14

We're using statuscake.io to do this. It supports email notifications.

This looks nice, particularly the automatic discovery.

Any monitoring system I've ever worked with can check for expired certificates. So usually the issue at previous jobs has been either there is no monitoring system (time to set one up!) or no SSL expiry checks are configured in the existing system (usually relatively straightforward to add manually or automate). I think I'd struggle to justify using yet another external service to cover that particular type of check.

Thanks!

The thing here is that you don't have to keep updating the app with every new host you create that needs to be monitored. CT allows me to detect newly issued certs in your domain, and start monitoring them without manual work on your behalf. And if you issue a cert with a hostname that doesn't yet have a DNS record, the app won't complain - no host means no live cert that can expire :)

Caveat - I have yet figured out how to apply this automated discovery for orgs that use wildcard certs... Suggestions are welcome :)

Is DataDog actually a customer you have a relationship with, or are you just checking their public certs? Would be interesting as they have this feature offered as a synthetic, but it is a good idea not to monitor yourself with your own tools.

Speaking of which, hosting your own status page is a bold decision that has burned many folks in the past. https://status.haveibeenexpired.com/

The 'companies we monitor' are just that - domains that I added to my own user in this app. Yes, it can appear shady, as if I was trying to hint that these juggernauts are my clients. They are not :) But hey, public servers are public, anyone can monitor them, right?

Re the statuspage - that's just a CNAME record, I'm a proud user of updown.io (which, btw, also offer SSL expiration checks for hosts they monitor!)

This looks quite helpful. Thanks for sharing. I always forget to renew the certs of my side projects on time so I think this would be a great product for me.

What are your side projects? Have you thought about automating this?

If you use LetsEncrypt and Docker, I can recommend HTTPS Portal to automatically manage your SSL certs: https://github.com/SteveLTN/https-portal

I use it for my blog and have never had any issues with certs being renewed well in advance of their expiration date.

I ask myself why a Google account is mandatory to use it. It’s probably a shortcut to not have to deal with a credential database. However, neither I nor any of the companies I work for would even consider this product for this very reason, despite it appearing to be quite useful.

I'm not keen on adding username/password registration, but I do have additional SSO flows behind the scenes:

GitHub - https://www.haveibeenexpired.com/auth/github Windows Live - https://www.haveibeenexpired.com/auth/windowslive

I can easily add more, and once this is needed by users, I will create a login page that lists all these options.

Oh wow, do tell me more please!

Indeed, I wanted to spare myself from implementing more detailed registration, but mainly wanted to keep the user from more steps in the registration process.

What would be an acceptable sign-in method for you?

Honestly, I'm just amazed at how this didn't exist yet... Awesome job Anton building this!

A side project of mine for your viewing pleasure!

Secret sauce - it uses https://certificate.transparency.dev/ to crawl your domain and automatically add new hosts for monitoring.

I tried looking for more information, but all I can see without logging in is the basics put up on the front page. So, I'll ask my questions here.

Is expiration monitoring done solely through certificate transparency logs or also by connecting to the host? I assume both, but I couldn't find a confirmation of this.

Can the service monitor hosts that aren't accessible publicly? For example, using an agent running inside a company's internal network.

If the answer above is "Yes" then a follow up question is: Does this service support certificate checking for certificates that aren't on certificate transparency logs? That is, certificates generated from a company's internal certificate authority.

> Is expiration monitoring done solely through certificate transparency logs or also by connecting to the host?

For every detected host, the app periodically performs an SSL handshake (HTTPS only), and checks for the expiration of the served cert. CT is used to detect new certs, and extract relevant hosts from these certs.

> Can the service monitor hosts that aren't accessible publicly?

Nope, this runs as a Heroku app right now, and will work with publicly accessible HTTPS-serving hosts only.

> Does this service support certificate checking for certificates that aren't on certificate transparency logs?

Yes, CT is used to detect new hosts automatically. The app also relies on the SANS of the certs it finds, spreading as wide as possible within the domain of interest. The actual checking of certs is a simple HTTPS handshake and inspection of the served cert.

I use Let's Encrypt certificates generated with certbot, it does automatically renew them and also let me know before they expire (via email). Would this service be better than certbot?

Cool. I have a script for that in a cronjob probing all my domains, but nice.

No IPv6 support? :-(

Hmmm I didn't add anything specific for IPv6, could be something related to Heroku (where my app is hosted). Can you share an IPv6-only host with me so that I can run some tests?

I've not used Heroku, but likely it's because they don't give you IPv6 in the thing that does the checking.

Try https://ipv6.google.com/

On your page I get:

    connect ENETUNREACH 2607:f8b0:4004:c08::8a:443 - Local (:::0)

Interesting, I was going to try it out, but after a quick scan of the Privacy Policy, it's not clear to me what lawful basis is being used under GDPR for the following:

> Do we share the information we collect with third parties?

> We may share the information that we collect, both personal and non-personal, with third parties such as advertisers, contest sponsors, promotional and marketing partners, and others who provide our content or whose products or services we think may interest you.

It seems like they are attempting to rely on implied/non-optional consent for everything:

> Your Consent

> We've updated our Privacy Policy to provide you with complete transparency into what is being set when you visit our site and how it's being used. By using our website, registering an account, or making a purchase, you hereby consent to our Privacy Policy and agree to its terms.

It doesn't seem like they are separating out their processing activities and assigning suitable lawful bases (contract/LI/consent etc.), which is a bit concerning.

This is an amazing input for me, thank you very much! I used a canned policy, and may have totally mixed a couple of things up. Will review and change it :)

I've been wanting a service like this forever.

:heart_eyes:

Reply on news.ycombinator.com