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.
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.
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!
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.
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.
> 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.
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.
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
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.
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].
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.
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.
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.
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.
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.
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 :)
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...
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.
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 :)
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:
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.
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.
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.
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.
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?
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?
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?
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 :)
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.