Dynamic Routing SSL Certificates

Three types of SSL certificates are relevant to Dynamic Routing for Liberty, the member certificate, the controller certificate, and the dynamic routing certificate. Each of the three types of certificate has an associated SSL signer certificate. An SSL signer certificate vouches for the validity of the certificate it signs.

Each of the following three types of certificates has an associated signer certificate:

Member certificate: The certificate that is presented by a collective member when the web server tries to proxy a client request to a member over SSL.
Controller certificate: The certificate that is presented by a collective controller to the plug-in when the plug-in tries to connect to the dynamic routing service on a collective controller.
Dynamic routing certificate: The certificate that is presented by the plug-in to the controller when the plug-in tries to connect to the dynamic routing service on a collective controller.

For SSL communication from requests that are proxied to collective members, the web server must trust that the member certificate is valid. For the web server to trust that the member certificate is valid, the member signer certificate must be in the web server keystore.

The keystore is the .kdb file that is referenced with the <Property Name="Keyfile" value=…/> xml element in the plugin-cfg.xml file.

For SSL communication between the plug-in and the dynamic routing service, the following conditions must be true:

The plug-in must trust that the controller certificate is valid.
The controller must trust that the dynamic routing certificate is valid.
The dynamic routing certificate must be authorized to access the dynamic routing service.

The dynamic routing certificate must satisfy one of the following conditions to be authorized:

The certificate subject matches the default certificate subject that is used by dynamic routing. The default certificate subject is created by default when the dynamicRouting command setup or genKeystore options are used. Following is the default certificate subject:
```
DC=com.ibm.ws.dynamic.routing,OU=dynamicrouting,CN=WebServer
```
The certificate subject matches the value of the certificateSubject attribute of the <dynamicRouting> XML element in the server.xml of the collective controller. If specified, this certificate subject is used instead of the default when the dynamicRouting command setup or genKeystore options are used. See the following example:
```
<dynamicRouting certificateSubject="CN=Plugin,OU=ops,O=MyCompany,L=Raleigh,ST=NC,C=US"/>
```
The certificate subject corresponds to a user in the security registry who is assigned the Administrator role. A dynamic routing certificate that has a subject with Administrator role allows access to administrative functions in the collective from the DMZ. If this type of certificate is used to access the dynamic routing service, an error message appears in the log, but the communication succeeds.

The dynamicRouting command setup and genKeystore options generate keystores with all of the certificates that are needed to ensure secure network communication between the web server and the servers in a collective. You do not need to modify anything if you want to use the default security configuration.

To use certificates that are not created by the dynamicRouting command setup or genKeystore options, the following conditions must be true:

The member signer certificates for all collectives are in the .kdb file that is referenced with the <Property Name="Keyfile" value=…/> XML element in the plugin-cfg.xml file.
Note: This is only required if the plug-in uses SSL to proxy client requests.
```
<Property Name="Keyfile" Value="/opt/IBM/WebSphere/Plugins/config/webserver1/plugin-key.kdb"/>
```
The controller signer certificate must be in the .kdb file that is referenced with the <Property name="keyring" value=…/> XML element of the <Connector> element for the controller in the plugin-cfg.xml file.
```
<Property name="keyring" value="/opt/IBM/WebSphere/Plugins/config/webserver1/plugin-key-collective1.kdb"/>
```
The dynamic routing signer certificate must be in the following directory of all the controllers:
${server.output.dir}/resources/collective/collectiveTrust.p12)

If you are using the JKS keystore through 19.0.0.2, use the following directory: ${server.output.dir}/resources/collective/collectiveTrust.jks)
The dynamic routing certificate for a collective must be in .kdb file that is referenced with the <Property name="keyring" value=…/> XML element of the <Connector> element for the controller in the plugin-cfg.xml file. See the following example:
```
<Property name="keyring" value="/opt/IBM/WebSphere/Plugins/config/webserver1/plugin-key-collective1.kdb"/>
```
The certificate subject in the dynamic routing certificate is one of the following options:
- ```
"DC=com.ibm.ws.dynamic.routing,OU=dynamicrouting,CN=WebServer"
```
- The value of the certificateSubject attribute of the <dynamicRouting> XML element in the server.xml files of the controllers in a collective.
- A user who is assigned the Administrator role in the collective, which is not recommended.