4 ms·

One issue is that HTTPS is one more thing to manage (no, it's not a complex thing to manage, but it is something). It's too easy for certificates to expire; it

by wtbob 12y ago

One issue is that HTTPS is one more thing to manage (no, it's not a complex thing to manage, but it is something). It's too easy for certificates to expire; it's psychologically irksome to pay the CA tax. I've seen many, many SSL expirations over the course of my career; far more than there should be, of course. Somehow we've ended up with a business culture which can track the number of left-handed albino Eskimos in middle management positions, but can't track certificate expiration dates. I don't know off the top of my head if it's possible to package two certs into one, so that one could have a certificate signed by one's own trusted root for one's own API client to trust, and a certificates signed by a CA for web browsers to trust, but that might make folks feel better about using it for an API endpoint: the own-trusted-root might have a different expiration period (risky), or an automatic renewal, or whatever. At the least it'd be self-managed to the point that the technical staff could handle it, rather than having to work through purchasing.

skywhopper 12y ago
This is a problem because the certificate handling is not in the hands of process managers, but in the hands of the sysadmins, who do not generally work on a rigorous business-cycle type of schedule, and who don't already have tools in place to keep track of such things, and have a hard time justifying creating a tool that would, assuming they just have one or two certs to manage, be used only once every two years (and thus would probably take four years to troubleshoot, by which point something about the assumptions would have changed, meaning the reminders/warnings would probably fail and the cert will get overlooked). It does make me wonder, though... why don't web servers have options to warn their admins (via logging or email or what-have-you) that the certs they are using are near expiration? Or do they? Alternatively, some good samaritan could set up a service to scan the known SSL web for near-expired certs and email webmaster@ or other scraped addresses of the issue.

by wtbob 12y ago

skywhopper 12y ago

This is a problem because the certificate handling is not in the hands of process managers, but in the hands of the sysadmins, who do not generally work on a rigorous business-cycle type of schedule, and who don't already have tools in place to keep track of such things, and have a hard time justifying creating a tool that would, assuming they just have one or two certs to manage, be used only once every two years (and thus would probably take four years to troubleshoot, by which point something about the assumptions would have changed, meaning the reminders/warnings would probably fail and the cert will get overlooked). It does make me wonder, though... why don't web servers have options to warn their admins (via logging or email or what-have-you) that the certs they are using are near expiration? Or do they? Alternatively, some good samaritan could set up a service to scan the known SSL web for near-expired certs and email webmaster@ or other scraped addresses of the issue.