Pro tip: Set up monitoring alerts on your SSL certs to alert your sys admin when they are getting close.
For example, here's a Nagios SSL expiration alert: http://exchange.nagios.org/directory/Plugins/Network-Protoco...
mike@alfa:~$ sslScanner.pl contracts.comcast.com news.ycombinator.com smtp.gmail.com:465
IP Address Port Days Left Common Name
126.96.36.199 443 -172 contracts.comcast.com
188.8.131.52 443 934 news.ycombinator.com
184.108.40.206 465 222 smtp.gmail.com
220.127.116.11 465 222 smtp.gmail.com
2a00:1450:400c:c00:0:0:0:6d 465 222 smtp.gmail.com
Disreputable CAs will email you 3-4 months before it expires, emphasising that you need to "ACT NOW" (GoDaddy is guilty of this).
/usr/lib/nagios/plugins/check_http --ssl -C 30 -H contracts.comcast.com
CRITICAL - Certificate expired on 05/08/2012 23:59.
openssl s_client -showcerts -connect contracts.comcast.com:443
To get the exact expiration date, it appears you have to do:
1) download cert:
openssl s_client -connect hostname:port > cert.pem
openssl x509 -in cert.pem -noout -enddat
It amazes me that these SSL errors stay this way so long. Even google has been guilty of this in the past.
I think the worst was I contacted them on twitter about several hosts that were hammering one of our mail servers, around a million lookups for usernames a day for each domain.
I blocked the IP's, problem solved, but wanted them to nuke the accounts. They said to send in the relevant data. I nicely formatted all the data, snipped sections here and there, and tar'd the files.
Emailed them in and was told they don't know what a tar file is. Sent them in gzip, they can't open them. Finally said screen it and posted the data to pastebin in plain text and sent them the raw link. They didn't know what to do with it.
At some point, I just gave up.
As for the question how to get the right person, I'd like to know a way...
Comcast.com is (stop laughing) a high value domain. You're not likely to get any CA to just hand over a certificate in 2 seconds. It will get flagged for manual inspection and further details will be required.
Large companies like this aren't as simple to handle. If it were a small startup with 3 people you want to bet your pants it would be fixed right away. But I bet you there are e-mails flying around into underpaid mailboxes waiting for a response. Not every corporate office is a well-oiled machine.
But on the flip side it is unfortunate they're struggling with it. The poor front line customer service rep (Carole) has no choice but to assure you they're currently working on it and move on to the next squeaky wheel. Like any person in customer service, her job is to assure you and move on.
Trying to impress first tier forum support with your long history with computers isn't helpful to anyone, and sounding off about a serious legal issue in bold and italics is probably just making the lawyers giggle. It's nice to report the problem and follow up on it. There's no reason to be a dick about it.
That might be acceptable advice on HN, but it's lousy advice for the general public.
Not caring about certificate expiration may be a sign of not caring about other, more serious, security issues.
If I connect using a protocol to a site, it should work! If said protocol is poorly configured, it shouldn't be available!
They should buy a wildcard cert for *.comcast.com and be done with it.
Best for everyone is to remain polite, responsive to the agent's requests (however seemingingly inane) and the process will move a lot quicker.
I sent him a tweet about this specific issue, and hopefully he can make this little embarrassment disappear:
You can make certs for ten, even twenty years.
This all goes back to the SSL cartel wanting control.
Just make a cert good until January 19, 2038 and get it over with.
Self-signed certs won't fly for public-facing websites.
CAs simply won't issue for more than 3 years, typically. They want to make money, and the easiest way to make more money is to make certificate lifetimes short.
There's an arguable security concern. If a site's cert gets compromised and it's not detected, having a shorter cert lifetime might in some situations prevent the compromise from persisting more than the certificate lifetime. True, if the server is compromised, you can replace certs every year and they'll all be compromised, but if it's a server farm with frequent reinstalls from trusted base media, server compromises won't necessarily persist, and compromised 5+ year website certificates might turn into the weakest link.
If the site must pass periodic scans (for example, by one of those PCI compliance outfits), most of those scanners consider more than 3 years to be "too long" for a cert to be valid. Whether they'd fail the site for that, I don't know.
Pretty sad for a company selling internet access to be so naive about basic things.
This is pretty damn pathetic (1), that's all I can think to even say.
(1) esp given that the cert expired in MAY.
* General ineptitude
* It's not something they monitor.
* The main www site is up, what's the problem?
* The technical contact for the previous certificate is no longer at the company. So the "expiring soon" notification was never received.
* The PO is awaiting 'approval', or Finance are sitting on it whilst arguing whether it's CapEx or OpEx, or the "Business Justification" was rejected by someone who doesn't understand, etc, etc.
HN doesn't really tolerate straight up mean comments.