I wrote an application a while ago which would connect to an SSL service and print out how many days until expiry. It works with network ranges and supports IPv6 also. It was designed with the aim of having something useful to stick in a cron job. So if you specify "--expires-within 14" for example, it will only output data for certificates that will expire within the next 14 days. For example:
mike@alfa:~$ sslScanner.pl contracts.comcast.com news.ycombinator.com smtp.gmail.com:465
IP Address Port Days Left Common Name
130.94.78.15 443 -172 contracts.comcast.com
174.132.225.106 443 934 news.ycombinator.com
173.194.78.108 465 222 smtp.gmail.com
173.194.78.109 465 222 smtp.gmail.com
2a00:1450:400c:c00:0:0:0:6d 465 222 smtp.gmail.com
mike@alfa:~$
It;s been more than a month, perhaps not this particular one, but I have reported to them on twitter multiple times that their SSL certs are dead. Their IP to geolocation is also way off, something they don't seem to care about.
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.
If they didn't know what tar file is, sending any format to that person would be useless - obviously, it's not the right person to talk to on this question, they are not nearly knowledgeable enough. I would guess it's some low-level support that is probably not even allowed to escalate the issue, and is not able to handle it, most they can do is to put the data into some kind of internal database where it quietly dies.
As for the question how to get the right person, I'd like to know a way...
If they can't open a tar, there's a good chance they can't open gzip either. I'd be willing to bet they run Windows on their desktops. Sending it as a Windows-standard zip might have been the better option.
To be fair to Comcast you're running into a few things. In a non-technical kind of way and in no order...
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.
It's pretty funny that an ISP can't get their certs together, but geez, temporarily accept the cert, read the service agreement and get on with your life. Are you seriously worried about a man-in-the-middle attack here?
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.
For some types of certificate errors, sure. But we're talking about expiration here. You can still check that the certificate was validly issued and (theoretically) that it hasn't been revoked. The certificate is only a year and a half old, compared to the verisign certificate with a 10 year life span that signed it.
I agree. To me the story here is that Comcast is a huge company that takes way too long to process simple changes. But in reality, who the fuck cares if the cert for that page expired? It's not like their collecting your bank records.
I know the warnings are in place for a reason, but why don't the affected people just bypass the warning. There is no reason to think that just because the date changed that Comcast's certificate is now compromised. If the certificate was issued with an expiry date of five years or more, I'd understand not taking the chance; especially considering how long Comcast is taking to review their certificate - if their certificate did become compromised their customers would likely never find out.
Dude if somebody wants to create a man in the middle attack to see my Comcast contract, that's cool. Hell, just email me and I'll send you a copy. I think context matters. I don't think most people would ignore a cert warning if they were about to do something they deemed private.
I doubt it. Steve Gibson once related how he sold many copies of his software on his website, even when the website accidentally had an invalid certificate. His software is geared towards a tech-savvy audience. If tech-savvy people don't behave securely, why should we expect most people to?
A little OT, but using HTTPS Everywhere has shown me how badly SSL is configured on many sites. Default certs for root domain being used on subdomains, scripts and styles loaded over HTTP (and hence blocked by Chrome - by far the most common and most annoying), HTTPS port listened on but no site served, default certs for completely unrelated sites showing up, etc.
Easy solution: stop using HTTPS Everywhere to force HTTPS in cases where the admins aren't supporting it. The admins haven't configured it badly, they've configured it for the cases they want to support. Using an extension to force non-standard behaviour breaks things.
Looks like their cert for https://www.comcast.com/ is fine, so this problem is only with the 'contracts' subdomain. I'm guessing that's a low traffic/priority section for them.
They should buy a wildcard cert for *.comcast.com and be done with it.
The "I was using the internet before there was an internet" argument is not helpful to anyone in this situation. The first tier support has no way of verifying the claim and even if they did, they still might not be able to escalate the issue before asking the documented questions. The questions in this case seemed quite sensible, I've been caught out with SSL certs expiring before realising my time wasn't syncing. It's not helpful to the OP because it comes across as arrogant and they're not going to endear themselves to the support agent.
Best for everyone is to remain polite, responsive to the agent's requests (however seemingingly inane) and the process will move a lot quicker.
In my personal experience, @ComcastBill, a fellow named Bill Gerth in Ohio(?), has been a responsive and helpful face inside Comcast. On two occasions short, specific queries his way resulted in receiving direct, actionable contact from inside Comcast.
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.
Ideally, the information in the certificate is vetted by the certificate authority. So, if you have your company name, physical address, and contact info in there, the CA would have actually conducted some checks to make sure that information was correct and not fraudulent before certifying it. That vetting process costs time and money. Unfortunately, nobody can detect whether it has happened so now we have $5 certs that are essentially unvetted (uncertified certificates?) because people are only interested in the encryption component.
The original post was on 2012-09-21 and still no resolution. Not to mention, as others have pointed out, it's for a cert that expired several months ago. But this link is public acknowledgement of the issue and it's still unresolved as of today. Regardless of bureaucracy, that should be considered highly unacceptable for the largest consumer ISP in the United States.
Look at the dates on the posts in the thread. He gave them a month before coming back and chastizing them again to find out they'd closed the ticket without fixing it.
This is pretty damn pathetic (1), that's all I can think to even say.
Probably. Never underestimate the bureaucracy of a big corporate entity (specifically when it comes to having to pay money to fix something).
Possible causes:-
* 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.
If you said, "I love when shit like this happens, because I've made the same mistake a million times and it makes me feel better seeing the big players do it" you probably would have even received a few upvotes.
HN doesn't really tolerate straight up mean comments.
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...