Introduction

...

• Server's public key (certificate) - it is located on the server-side and is shared with the counterparty during the handshake procedure. 
  It is mandatory for FIX acceptors.
• Server's private key - it is located on the server-side and shouldn't be shared. The key is used for encrypting the message.
  It is mandatory for FIX acceptors. 
• Client's public key (certificate) - it is located on the client-side and is shared with the counterparty during the handshake procedure. 
  Optional for initiators. Without it, the client will be able to establish a secure connection (1-way TLS) and verify only the server.
  It is specified the initiator can use 2-way TLS authentication and the server will be able to verify the client.
• Client's private key - it is located on the client-side and shouldn't be shared. 
  Optional for initiators. Should be used in case of 2-way TLS authentication so will be able to verify the client.
• CA certificate - Certificate signed by 3rd party and trusted by both Server and Client.
• Certificate Signing Request (CSR) - the file that the applicant sends Certificate Authority for getting the CA certificate.
• Certificate stores - various containers for certificates. Usually protected with passwords
  Java products expect certificates and keys in their own Java containers (*.jks) and do not use plaintext files (for example in *.pem format).
  
  • Java Key Store - store for certificates containing certificate-keys pairs. 
  • Java Trust Store - storage for all trusted certificates. Usually, it holds CA certificates.

...

There are a lot of SSL protocols. FIXEdge supports SSL v2.0, SSL v3.0, TLS v1.0, TLS v1.1, TLS v1.2, TLS v1.3. By default only TLS v1.0, TLS v1.1, TLS v1.2,TLS v1.3 protocols are enabled in FIX Edge.

...

1. Create the self-signed SSL certificate and the private key via OpenSSL.
   The instruction about how to create such a certificate and key can be found here: SSL with self-signed certificates
   This type of certificate is only suitable for the testing period because most clients don't trust self-signed certificates.
2. Prepare a Certificate Signing Request (CSR) from a Certificate Authority (CA), for example, "DigiCert".
   In order to do it, you should create the private key file and then generate CSR.
   You can find the instruction here: https://www.ssl.com/how-to/manually-generate-a-certificate-signing-request-csr-using-openssl/
   During this process you have to provide the following information for CA:
   

   1. commonName (for example, “CN=B2BITS”)

   2. organizationalUnitName (for example, “OU=Dev”)

   3. organizationName (for example, “O=EPAM Systems”)

   4. localityName (for example, “L=Newtown”)

   5. stateOrProvinceName - should not be abbreviated (for example, “S=Pennsylvania”)

   6. countryName - two-letter ISO code for the country where your organization is located (for example, “C=US”)

   7. emailAddress - an email address to contact the organization. Usually the email address of the certificate administrator or IT department

   CA will create the SSL certificate based on provided information. After that you should install this certificate on your server.

...

Self-signed certificates can be used in some cases (for testing purposes). Before creating certificates, make sure that OpenSSL Toolkit is installed.

First of all you have to create Certificate Authority (CA) certificate along with its private key. Use the following command file to generate the Private key (line 1)  and SSL (Certificate Authority) CA root certificate (line 2) files that can be used to generate further certificates:

...

%1 - file name for certificate (.crt) and private key (.key);

%2 - common name (CN), can match the organization name for the CA certificate.

CA certificate allows is used to create and sign other certificate. 

Use the following command file to generate

• Certificate (.crt),
• Private key (.key),
• Encrypted Private key (-enc.key), 
• Certificate and Private key in .pfx format.

openssl genrsa -out %1.key 2048
openssl rsa -in %1.key -out %1-enc.key -aes256 -passout pass:%1
openssl req -new -key %1.key -out %1.csr -subj "/C=RU/ST=%1/O=EPAM/CN=%3"
openssl x509 -req -in %1.csr -CA %2.crt -CAkey %2.key -CAcreateserial -out %1.crt -days 5000
del %1.csr
del %2.srl
openssl pkcs12 -inkey %1.key -in %1.crt -export -out %1.pfx -password pass:%1

...

%2 - file name of CA certificate (.crt) and its private key (.key);

%3 - common name (CN) is used to define the server name which will be used for secure SSL connection.  Your SSL certificate is valid only if hostname matches the CN.

Server verification by the client and client verification by the server are possible. Two CA certificates and two certificates signed with that CA certificates respectively are required two utilize both sides verification at the same time.Both types of verification are supported by FIXEdge.

How to validate the SSL certificate

...

The article which describes how to configure FIXEdge for SSL connection can be found here: How to configure built-in SSL support for FIX session sessions in FIXEdge