Along with basic information about certificates, this section now considers their concrete application in establishing VPN connections. For connection establishment with the support of certificates, certain information must be available at both ends of the connection (e.g. when connecting a branch office to the network at headquarters by means of a router):
- The branch office has the following components:
- The Root CA's certificate with the CA's public key
- A certificate for its own device with its own public key and the confirmation of identity. The check sum for this certificate is signed with the CA's private key.
- Its own private key
- The headquarters has the following components:
- The Root CA's certificate with the CA's public key
- A certificate for its own device with its own public key and the confirmation of identity. The check sum for this certificate is signed with the CA's private key.
- Its own private key
Put simply, the following procedures are carried out during the VPN connection exchange in Main Mode (symmetrical in both directions):
- In an initial exchange of packets the peers negotiate, for example, the encryption methods and the authentication method that are to be used. At this phase, both ends are not fully certain about who they are negotiating with, although this is not yet critical.
- At the next stage, common key material is negotiated for the continued communications, including among other things symmetrical keys and asymmetrical key pairs. At this phase, too, the two ends are not yet fully certain about who the keys are being negotiated with.
- In the next stage, the certificate is used in a check to ensure that the peer involved in negotiating the key material really is the intended communication partner:
- The branch office uses the current negotiation's key material to calculate a checksum (hash value) that can only be calculated by the two peers involved (branch office and headquarters) and only so long as the connection exists.
- The branch office encrypts the hash with its own private key, generating a signature with it.
- The branch office then transmits this signature together with its own certificate to the peer at headquarters.
- The headquarters then checks the signature of the certificate received from the branch office. This can be done with the help of the public key at the Root CA, which is identical for both peers. If the signature in the branch office's certificate (generated with the CA's private key) can be decrypted with the CA's public key, then the signature is valid and the certificate is trustworthy.
- In the next stage, the headquarters checks the signature of the encrypted hash. The branch office's public key in the corresponding certificate was found to be valid at the previous stage. The headquarters can thus check if the signed hash can be decrypted with the branch office's public key. The headquarters can calculate the same hash as the branch office using the key material for the current connection. If this check is successful then the peer "branch office" can be considered as authentic.
