I hope the fact I wrote and posted this on a weekend isn't lost on you! :)
26 karma · joined October 25, 2016
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.
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.
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 hear what you are saying about the credibility hit I'm taking with showing logos like this. Will think what to do about it!
> 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.
The automated monitoring (once you sign up and add domains/hosts) only checks HTTPS, so no dice there...
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?
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 :)
Webhooks are... easier to consume.
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!)
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 :)
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 :)
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.
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 :)
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.
Thanks for this feedback!
Secret sauce - it uses https://certificate.transparency.dev/ to crawl your domain and automatically add new hosts for monitoring.