Replace all Certificates

When talking about security, SSL, the SSL Certificates, it does happen that there is a policy in place for "regularly" replacing the Certificates. What is "regularly"? That varies and can be anything between 3 months or 3 years. The length of time a Certificate can be considered as OK depends on various factors, like for what it is used, who is using it, etc. And it depends on whether or not 1 or more "other" companies, organizations, are involved in generating and verifying the Certificates. Certificates in Browsers for example, which are used to secure the SSL connection with webservers, use a multitude of third parties to verify the Certificates. The Browser needs to have trust in all those third parties; hopefully it does not happen that a third party has a security problem, due to which the Certificates can not be trusted and a Man-In-The-Middle attack can be done...

Because the SSL Gateway does generate its own Certificates, and it has no dependency at all on any third party for checking the validity of the Certificates, the SSL gateway has no need to trust anyone else in the world (including us, AADS WorldWide). Therefore the SSL Gateway generates Certificates that can be used for 10 years.

Despite the previous statements, if there is a "reason" to replace all Certificates sooner then those 10 years, such can be done as follows:

Example

1. Current Certificates

2. Generate a new Server Certificate.

The current Server en Client Certificates will be renamed and appear as "Other Certificates and Keys".
They can now be called the "previous / old" Certificates:

• The Server- and Client Name will not be renamed.
• It is the FileName that will be renamed; the FileName has a number-prefix.

Because this is "only" an example, the "old / previous" Certificates are "only" a few minutes old in this example.
Usually the Administrator would do this procedure, for example, after 3 years, implying that the "old / previous" Certificates will show a Valid After date that is 3 years old.

As long as the "old / previous" Certificates are not deleted from "Other Certificates and Keys", they can be used and the users can continue to work using the "old / previous" Server and Client certificates.

3. Generate new Client Certificates

4. Generate Client Builds

• Client Builds are generated in this example for Sales, Store East and Store West.
• Client Builds for Windows, OSX and Linux x64. In total 9 Client Builds:
  • 3 Client Build for Sales: Windows, OSX and Linux x64,
  • 3 Client Build for Store East: Windows, OSX and Linux x64,
  • 3 Client Build for Store West: Windows, OSX and Linux x64.

5. Distribute and Install the Client Builds

Give yourself and the users a reasonable period for distributing and installing the Client Builds. For example, 2 weeks.
In those 2 weeks all users are required to update their PC/Mac and install the new Client Build.

6. Delete the "old/previous" Certificates

After the reasonable period, delete the "old / previous" Server and Client Certificates from "Other Certificates and Keys"

When the "old / previous" Certificates are deleted, only Client PC's which have installed the new Client Build can connect to the Server.