Just another not bad tool. If you don’t have a wildcard certificate in use, probably you have many of them and in many places.Usually such kind of system is being monitored automatically with some system (OpsMgr, nagios, custom software), but sometimes you just need to get an overview of what’s happening right now. In this case you can use some report if you have one suitable, or write your own report, or use the following tool: VerifySSLSertificate.It’s small, robust and have just several but essential functions and settings. You can save and load a list of servers to check, save a certificate from a server and set a warning threshold. That’s it. Do you need more to get a brief overview? I doubt it, to be honest, it is quite visual:
That’s one of the referrers from search systems which leads users to my blog. Ok, there certainly are drawbacks, so why not? But first things first: what are those wildcard certificates?
In order to protect communications with some web-services or web sites (not only them, actually) we use SSL certificates. I have to say, that it doesn’t, actually, mean that every site with https prefix and valid certificate is valid itself or communications with it are protected, but that’s not for today’s discussion. Anyway, SSL certificates are somewhat brilliant and somewhat ugly, but they are our reality for now and since you have many web-sites, or medium to large infrastructure which uses multitude of services protected by certificates… That’s because a certificate is issued for one particular domain name, that is microsoft.com, www.microsoft.com and technet.microsoft.com should all have different certificates for their protection. Well, in such situation you are usually bound to manage dozens and hundreds of certificates which expire, need to be renewed, need to be monitored… The hell of a job. But “security is security” and all that stuff, so you are to do it all.
But the world wouldn’t see many inventions if not for lazy people, you know. So those lazy invented wildcard certificates. Those are issued to names like *.microsoft.com and hence can be used on any of microsoft.com’s subdomains. That solves all the problems above. Or does it? Indeed it does. But nothing comes without cost, remember? This case is not an exception from the rule. If you use a wildcard certificate in your organization you have one secret key on every your box which needs a certificate (there are services which allow you to create multiple wildcard certificates with one name, but different secret keys… But then why even bother to do that?). Statistically that does mean that you are increasing the risk of compromising this one particular certificate. Some don’t think this is a problem, well. Why bother with certificates at all, then? =) Suppose, we are not those guys and we think that compromising of the certificate for several dozen services is a problem but not very big one: we’ll just need to get one new and spread it over our sites. But, since we had this certificate compromised, we can consider any of our services as a such as well. So we need also audit these systems to find out if they are ok. And, believe me, it is very expensive.
To sum up: I’m definitely not fond of the solution. At least for now. you may and should decide on your own. =)
I’ve received a question through the Russian TechNet Forums, answer to which is to be widespread. The fact is that the CRL checking process has been change in IE7 in case CRL is not reachable. While IE6 shows the warning in that case, IE7 by default doesn’t show anything. It is easy to think up the situation (which is, fortunately, harder to implement) which will lead to some problems due to such a behavior of the browser.
It is quite easy to switch the thinks back, just add the following key to the registry:
After that we will receive beautiful, extremely cheerful yellow warning in the address line:
Of course I must warn you of necessity to backup registry before the procedure.