distributing SSL certificates?



  • 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...



  • 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.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2