5

I'm only familiar with SSL certificates in a simple-use case: I've installed them to websites, Windows servers, and a few Linux servers.

I'm now faced with the task of securing every possible device in our international network with SSL certificates. I've purchased a wildcard *.mydomain.com certificate from Comodo so that I can use the same certificate everywhere, but I'm still faced with the mountainous task of installing certificates to many Windows servers, apache servers, Linux servers of various flavors, proprietary OS's, desktops, and even printers.

What is most daunting about this task is that I will need to do it again and again - every time the SSL certificate expires. I know I can purchase a 5-year certificate, but even still, it is a hassle I'd rather not have to repeat.

Is it possible to have one system (like a Windows domain server) act as a certificate server and then just load every other device with a certificate that "points" to the certificate server for validation? My idea is that I would only have to update the certificate in one central location, and then all the other devices pointed to that server would automatically be current. I've already noted that there are concepts like "Intermediate CAs", "Certificate Chains" and "Local CA Authorities", but I'm not sure if it is possible to leverage those concepts into helping me distribute a certificate from a big-name CA down the network...

Improve this question
1
  • 4
    I think your question might benefit from a bit more background on why you've been tasking with installing an SSL certificate on every machine in your network (i.e. what business problem is being solved by doing this) as it may be that there's other ways to accomplish the goal with less hassle, but it's hard to tell if those will be appropriate without knowing the underlying reasons for the deployment.
    – Rory McCune
    Commented Jun 5, 2015 at 15:28

3 Answers 3

Reset to default
6

In order to perform this task, you typically rely not on a single cert but on an internal certificate authority.

You first setup your own , off-line root CA and then immediately setup at least one (usually more) intermediate certificate authority with keys signed by your private root (if you're using a windows AD infrastructure, these ICAs can be setup using windows certificate services server and then integrated within you AD).

Once properly deployed (which isn't a trivial task), then you can generate and renew certificates for your servers very easily.

The weak point of this strategy is that it typically only works internally: external systems will not recognize your root as valid. A typical method of solving this is to use reverse proxy servers placed at your perimeter that will offer to external clients a certificate signed by a public root and connect to the internal systems. Since these proxies should have your private root installed, they will be able to validate your connections.

Note that this is a very high level description of the strategy: implementing it securely and globally is not easy and should be done extremely carefully.

Improve this answer
5
  • 1
    This sounds like it might be getting at what I want, so the question is what keywords and/or what guides do I need to search for in order to do this the right way?
    – Daniel
    Commented Jun 5, 2015 at 15:45
  • @Daniel There are a number of resources available on MSDN and Technet. Here's one detailed guide: technet.microsoft.com/en-us/library/hh831348.aspx
    – Xander
    Commented Jun 5, 2015 at 15:47
  • Does this kind of solution work with nonWindows systems? I have Linux servers and other systems running proprietary OS's
    – Daniel
    Commented Jun 5, 2015 at 19:15
  • 1
    Yes @Daniel. This relies on X.509 semantics, not OS behavior. The details of importing the certificates will vary by OS. Google importing certificates linux for details.
    – Neil Smithline
    Commented Jun 5, 2015 at 21:24
  • @Daniel You can even implement it using different software stack for the different components. An AD-integrated Windows Certificates Services serveur is a very convenient way to deploy an intermediate certificate authority but it can use a root generated and maintained using, for instance, OpenSSL (which is convenient for an offline root)
    – Stephane
    Commented Jun 8, 2015 at 7:56
0

The question suggests a using a certificate server to load new certificates onto other servers which is problematic.

The question however hints at the need for identifying when certificates expiry. As an example, the CA DigiCert, provides a Certificate Inspector tool which appears to automate some of these tasks. Refer to this link https://www.digicert.com/cert-inspector.htm.

Improve this answer
0

I've purchased a wildcard *.mydomain.com certificate from Comodo

So if any machine is ever compromised you need to revoke the existing certificate, buy a new one and deploy it to all the hosts?

You didn't provide much detail on the number of end points and the work involved in applying the certificate. Also the frequency will depend on external factors, but if its more than a few end points, it would be less cost and effort to run your own CA.

Note that you could achieve the same result if you had a certificate-signing-certificate from "a big-name CA" - but you don't even want to ask how much they would charge for such a thing.

Is it possible to have one system (like a Windows domain server) act as a certificate server and then just load every other device with a certificate that "points" to the certificate server for validation?

Yes. I believe Active Directory does this for some MSWindows services (RDP, IIS, AD).

There are lots of orchestration tools available for deploying certificates. I had this configured on Linux 18 years ago covering an estate of Linux, MSWindows, HPUX servers, MSWindows desktops and field laptops. Then I had to build much of the integration myself.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .