This article is part of our ongoing UpGuard 101 series that focuses on ways to use UpGuard to keep your environment ready and yourself sane in real world scenarios.
People keep track of SSL certificate expiration in many different ways: emails from the certificate provider, scripts that poll occasionally and log or report information, post-it notes, strings tied around fingers... but ensuring overall resilience requires a more comprehensive and visible strategy, especially since SSL is crucial to a website’s security rating. With UpGuard, we can manage certificate expiry by policy like any other configuration attribute by taking advantage of the time comparison functionality.
You manage several web servers for your company, each of which uses a 1-year SSL certificate from a trusted third-party authority to encrypt communications. Because these servers grew organically with the business, the expiration dates for their certs are scattered across the calendar. You need a reliable way to ensure none of the certificates come within 30 days of expiring. Since your organization was smart and got UpGuard for configuration monitoring, this shouldn’t be much of a problem.
Adding the Websites
The first thing we need to do is create a node group in UpGuard for our sites against which we can apply the policy. Choose add node group on the left and name it Websites. Next, we’ll add all of our websites as nodes. In the add node menu, just choose Website and enter a name, description and the URL of the site. The website will be scanned automatically. Once we’ve added all of the websites as nodes, we need to add the nodes to the Websites node group we previously created.
Creating the SSL Certificate Policy
WIthin the scan results of our website, we can drill down to Web > SSL > Expires. Here we see the expiration date of the cert in the value field. Now we can build a policy from this.
Right click "Expires" and choose add to policy, then browse to the Websites node group and choose new policy. We’ll name this one “SSL Expiry 45 Days” since that will notify us in plenty of time to get the certificate renewed before it only has 30 days left. Once the policy is built, you can see in the results pane that the Expires block turns green.
We’re not done yet, though. By default, the policy that is created uses an exact match operator, which in this case won’t do us any good, because the expiration date of the certificate isn’t going to change. We need to edit our policy by going to Policies in the UpGuard menu bar and then choosing our SSL Expiry 45 Days policy. Drill down here under Web to Expires. We’re going to want to edit the Value policy and change the Exact Match operator to Time Comparison. Next we’re going to add our time comparison operator by choosing > from the pulldown menu and entering “45 days from now” into the text box. As best practice, we should also update the Background field and leave comments on why we built this policy. Click done to save the new criteria.
Using the Policy
Let’s rescan the website with our new policy. Fortunately, our certificate still passes the check because it’s more than 45 days until it expires. But if we want to make sure the policy will work, we can enter a longer interval and force a policy failure. Also, because we applied this policy to our websites node group and added our sites to that group, the other websites will automatically have this policy applied to them. If we rescan the entire group, any that are within 45 days of expiring will fail, and we can configure alert actions for what happens if they do.
If we add websites into the node group as they are brought into our environment, we know their SSL certificates won’t expire without notification. Likewise, if we have other requirements that apply to all of our websites, we can add those configuration items to this policy and ensure all nodes under the websites group meet our pre-established criteria.
The time comparison operator in UpGuard’s policies can be a great way to centralize management of those configurations that need to be updated on regular intervals, such as domain or SSL certificate expiration. The website type of node has plenty of other useful information as well, such as SPF and TXT DNS records, additional SSL info such as the algorithm used (do you have any SHA-1 certificates in production?) and what scripts are running on the homepage. The key feature here is that we’re not just answering a question once for a given point in time, but rather producing a mechanism to always easily know the state of that information in the future. This provides testable, reproducible configurations, which means fewer outages and vulnerabilites for applications and fewer headaches for the people who manage them.
We’re going to compare how Tripwire to Puppet fit into an IT environment.
Read Article >
Windows 7 has its own set of critical vulnerabilities—here are the top 11 on the list and how to fix them.
Read Article >