Appendix A: Using SSL Certificates

SSL stands for Secure Socket Layers, and TLS—for Transport Layer Security. Both are cryptographic protocols that provide data encryption and authentication between different computers in a network.

SSL is the older protocol, which is now deprecated, TLS being its successor. Since the certificates used for secure connection are not the protocols itself, the certificates are commonly referred to as SSL certificates or SSL/TLS certificates.

SSL certificates

To use TLS, you need a certificate in the PEM (X.509) format. The certificate consists of a certificate file and a key file.

There are three general steps to obtaining a certificate. These three steps are carried out differently for each web server, but their purpose remains the same.

1. Generate a private server key. This key is later used to encrypt the outgoing data.
2. Generate a Certificate Signing Request (CSR). The CSR is linked to the key, the identity of the server's owner, and the URL of the server. The server URL is stored in the common name (CN) field of the certificate.
3. Obtain Certificate Authority (CA) signature. The CA signs the CSR after verifying that the holder of the CSR and private server key matches the identity specified in the CSR. The signed CSR is the certificate. Because the receiving party trusts the CA, the CA signature proves to the receiving party that the certificate holder really is the one named in the certificate.

There are three ways to sign the CSR:

1. The first one is to have it signed by a publicly known Root Certificate Authority, such as Verisign or Thawte. This is the optimal solution, since these Root Certificate Authorities are well-known and trusted.
2. The second alternative is to have another CA, such as an in-house IT department or a lesser known third party CA, sign your CSR.

   When using a CA that is not well-known, it is necessary to distribute the CA’s certificate to clients. Keep in mind that the CA’s certificate is independent of the server’s certificate. Without the CA’s certificate, the receiving party cannot trust the CA and therefore cannot assign any validity to the CA’s signature on the server certificate.

   CA certificate distribution can be done easily via the web server itself or with MassTransit, but for security reasons, the fingerprint of the certificate must be communicated securely and it must be verified. If the receiving party is able to verify the fingerprint of the CA certificate, then the recipient knows they have an authentic CA certificate and not a spoof.

   The task of distributing CA certificates to web browsers is complicated by the fact that different browsers expect the CA certificate to be distributed in different formats. The default format for keys, requests, and certificates, is PEM. Some older browsers might only accept CA certificates in DER format.

3. The final method of signing the CSR is to self-sign it with the private server key. A self-signed certificate allows encrypted communication but provides no guarantee whatsoever that the holder of the certificate has any connection to the identity specified in the certificate. Without proof of identity, the client cannot distinguish between communications with the true server and a spoof. As such, self-signed certificates don't offer true security and should only be used for testing purposes.

   Note: Microsoft IIS cannot use self-signed certificates.

Web server certificates vs. MassTransit server certificates

The MassTransit certificate has a different purpose than the web server certificate.

Since the web server and the MassTransit server cooperate closely when communicating with web clients, there is no need for the MassTransit Assistant to verify the identity of the MassTransit server: the MassTransit server is automatically known to be the same entity as the web server.

In communication between web clients and MassTransit server, it is not important whether the MassTransit server uses a CA signed certificate or an automatically generated, self-signed one.

In communication between two MassTransit servers, however, the web server is not involved and cannot act as a proof of identity. in this case, you must use CA-signed certificates for MassTransitservers in order to have truly secure communication.