Protect Server Authentication

Server Authentication Protection

[1] When manually installing an SSL Certificate [2], the Administrator must enter the ‘Root’ password for the server. This means that the Administrator has the unique username and password that enables them to access the core of the machine and although this is not the preferred security, it is acceptable on the assumption that the Administrator is careful where these access details are stored and also controls who has access to them.

The username and password authentication of the Administrator to the system is as strong as the password used and the security of how the password is protected. In the event that a single server’s password is compromised, the rest of the servers on the network remain unaffected. This is a common practice in most organisations and can be considered as an acceptable layer of security, but as AACD™ demonstrates, there is a superior method.

As previously explained, in the central server SSL managed system, passwords are stored at the central location. Access to this central server is most probably protected by another username and password. In this environment, it is therefore easier to gain unauthorized access to the entire network by simply compromising this single, central server. With the central server’s username and password compromised, the entire network is vulnerable. As authentication from the central SSL management server is by username and password, server authentication is undermined in this system’s design.

The DSSA™ [3] software that is installed on each server has a unique and trusted relationship with the CSG™ [4] and the CA [5] that it communicates with. This authentication uses encrypted connections and two factor client Certificate authentication between the DSSA™ and the CSG™ and subsequently the CSG™ and the CA. This military grade security cannot be compromised because each individual server must authenticate to the CSG™.

Before the DSSA™ can function, it must first initiate and successfully complete an authentication process with the CSG™. This authentication uses a Unique ID [UID] Key that is embedded in the accompanying config.txt file for that specific DSSA™. The UID is an encrypted string that cannot be compromised and is issued by the CA for use by the specific DSSA™ in the organization. This UID is in an one-time-only transaction to authenticate the DSSA™ to the CSG™ so that the two devices can exchange the two factor authentication [6] Certificates. This is the third layer of security used to protect the server in the AACD™ system and further improves the overall security of your environment.