Creating the keystore for a database server

About this task

As TLS server, a database server needs to own a private key and the corresponding certificate. Both items should be stored in a PKCS #12 keystore file. To avoid the disadvantages of using self-signed certificates (as explained in the topic "Concepts of Keys, Certificates and Keystores for TLS"), the database server should use certificates issued by a CA. However, requesting and receiving certificates from an established commercial CA may be a slow process and usually even costs real money. The compromise between these two possibilities is to use the in\u0002house CA that was set up as shown above.

Procedure

Create an empty keystore for the database server:
```
 $ gsk8capicmd -keydb -create -db server1.p12 -pw s1passwd -type p12
```
The command creates the empty keystore in file "server1.p12". This keystore is protected with password "s1passwd". The option "-type p12" specifies the format PKCS #12 for the keystore.
Create the database server's certificate request and private key in the keystore:
```
$ mydn="C=US,ST=Florida,L=Anytown,O=Acme Software Inc.,OU=DB Servers"
 $ mydn=${mydn}"CN=DB Server 1/emailAddress=db1@acme.info"
 $ gsk8capicmd -certreq -create -db server1.p12 -pw s1passwd -label server1 \
 > -dn "${mydn}" -size 2048 -file server1.req.pem -sigalg SHA256WithRSA
```
The command creates a new certificate request and implicitly the corresponding private key in the keystore file "server1.p12". The certificate request has the label name "server1" and specifies as signature algorithm "SHA256WithRSA". The size of the private key is 2048 bit. The option "-file ..." writes the certificate request also to the output file "server1.req.pem" in PEM format.

The option "-dn ..." specifies the subject name of this database server. For convenience, the longish subject name is given as the variable "${mydn}", defined by the previous two shell commands. This subject name is a distinguished name that consists of several fields like country, state, location, organization, organizational unit, common name, etc. The fields in the string are separated by comma.
The content of the keystore can be shown with the following command:
```
 $ gsk8capicmd -certreq -list -db server1.p12 -pw s1passwd
 Certificates requests found
         server1
```
Details about the certificate request with label "server1" can be obtained with this command:
```
$ gsk8capicmd -certreq -details -db server1.p12 -pw s1passwd -label server1
 Label : server1
 Key Size : 2048
 Subject : "OU=DB ServersCN\=DB Server 1/emailAddress\=db1@acme.info,O=Acme Software
 Public Key
     30 82 01 22 30 0D 06 09 2A 86 48 86 F7 0D 01 01
     ...
 Public Key Type : RSA (1.2.840.113549.1.1.1)
 Fingerprint : 
 d2e35afe6abf8bdf8d9d00ea6bde33e9
 c1030a7a
 Attributes
 Signature Algorithm : SHA256WithRSASignature (1.2.840.113549.1.1.11)
 Value
     C1 53 33 3C C1 0F E6 26 25 D8 45 E5 C4 A7 AF 93
     ...
```
As CA sign the new certificate requested by the database server:
Note: This step is performed in the role of the CA.
```
$ gsk8capicmd -cert -sign -db rootCA1.p12 -pw r1passwd -label rootCA1 \
 -target server1.cert.pem -format ascii -file server1.req.pem \
 -ca false -sigalg SHA256WithRSA
```
The command uses the keystore owned by the CA, file "rootCA1.p12", with the corresponding password "r1passwd". The option "-label ..." specifies that the certificate and corresponding private key with label name "rootCA1" are to be used for the signing of the new certificate. The new certificate is written to the target file "server1.cert.pem", in PEM format as per the given option "-format ascii". The new certificate is created based on the certificate request from the database server, provided in file "server1.req.pem".

The option "-ca false" makes the new certificate a user certificate, in GSKit terminology also called a personal certificate. With that, the new certifciate can be used by an TLS server, but cannot be used as an intermediate CA certificate.

The option "-sigalg SHA256WithRSA" ensures that the new certificate is signed with the algorithm "SHA256WithRSASignature" to make it compatible with different crypto libraries.

By default, the new certificate is valid for one year, beginning with the time of issuing the certificate. A different validity period can be specified with the option "-expire ". However, the start time of the validity is always the time of issuing the certificate. (In fact, the start time is one day earlier to avoid otherwise possible issues with different time zones.)

As the CA, the newly issued user certificate is handed together with the previously extracted "rootCA1" certificate in file "rootCA1.cert.pem" to the user who requested the new certificate.
Put the root CA certificate into the database server's keystore:
After having received the requested user certificate together with the root CA certificate from the CA, these certificates can now be put into the database server's keystore, beginning with the root CA certificate in file "rootCA1.cert.pem".

In order to make the database server's keystore functional for TLS communication with GSKit, this keystore not only needs to contain the database server's own user certificate (aka personal certificate), but also the complete chain of certificates that were used to sign the database server's user certificate. In the example at hand, the database server's user certificate was signed directly with the root CA certificate. No intermediate CA certificates were used. Therefore, it is sufficient to just put this root CA certificate into the database server's keystore. It is best to do this step first, i.e. before also adding the database server's user certificate to the keystore. This way, the chain of CA certificates (in the example just the root CA certificate) is already available in the keystore when adding the new user certificate. With that the user certificate can be validated immediately when adding it.
```
 $ gsk8capicmd -cert -add -db server1.p12 -pw s1passwd -label rootCA1 \
 -file rootCA1.cert.pem -format ascii
```
The command adds the root CA certificate to the database server's keystore in file "server1.p12" using password "s1passwd". The certificate is stored in the keystore with label name "rootCA1". The certificate to add is in the input file "rootCA1.cert.pem", a PEM file as per the option "-format ascii". This is the PEM file with the root CA certificate that was extracted from the CA's keystore as last step of setting up the in-house CA described above.

The label name "rootCA1" is by choice the same as the label name of the same root CA certificate in the CA's keystore. This allows for quickly identifying the root CA certificate in the database server's keystore. The two keystores (of the database server and the CA) are completely separate keystores. Therefore, the label name of the root CA certificate can be diverse in the two keystores. Choosing the same label name is done just for convenience.
The root CA certificate in the database server's keystore can now be seen with this command:
```
$ gsk8capicmd -cert -list -db server1.p12 -pw s1passwd
 Certificates found
 * default, - personal, ! trusted, # secret key
 ! rootCA1
```
As expected, the certificate is shown as "trusted", which means that it is a CA certificate. Details of the certificate can be shown with the command:
```
$ gsk8capicmd -cert -details -db server1.p12 -pw s1passwd -label rootCA1
```
The output is the same detail information shown for the same certificate in the CA's keystore (see above).
Add the database server's own user certificate to the database server's keystore:
The database server's keystore still contains the certificate request and the corresponding private key. The new certificate of the database server, signed and issued by the CA in step 3 above and received from the CA in file "server1.cert.pem", needs to be associated with the private key and the certificate request. Therefore, the new certificate is not merely "added" to the keystore, instead it is "received". The options "-cert -receive" accomplish this operation correctly:
```
$ gsk8capicmd -cert -receive -file server1.cert.pem -format ascii \
 -db server1.p12 -pw s1passwd
```
The command "receives" the database server's user certificate in file "server1.cert.pem" of format PEM into the database server's keystore "server1.p12". Password "s1passwd" is used to access this keystore. This certificate in file "server1.cert.pem" was signed and issued by the CA in step 3 above.
The new user certificate in the keystore replaces the certificate request for which it was issued. After the receive operation, the new certificate is listed as personal certificate in the keystore:
```
$ gsk8capicmd -cert -list -db server1.p12 -pw s1passwd
 Certificates found
 * default, - personal, ! trusted, # secret key
 ! rootCA1
 - server1
```
As can be seen, the new certificate is stored with the label name "server1" as this was the label name of the replaced certificate request. The certificate request is no longer in the keystore:
```
$ gsk8capicmd -certreq -list -db server1.p12 -pw s1passwd
 No certificate requests were found
```
Details for the database server's certificate can be shown with the following command, specifying the label name "server1":
```
$ gsk8capicmd -cert -details -db server1.p12 -pw s1passwd -label server1
 Label : server1
 Key Size : 2048
 Version : X509 V3
 Serial : 35
 Issuer : "CN=Database CA Root1/emailAddress\=dba_ca1@acme.info,OU=Database CA,O=Acm
 Subject : "OU=DB ServersCN\=DB Server 1/emailAddress\=db1@acme.info,O=Acme Software
 Not Before : November 15, 2022 5:02:07 AM CST
 Not After : November 16, 2023 5:02:07 AM CST
 Public Key
     30 82 01 22 30 0D 06 09 2A 86 48 86 F7 0D 01 01
     ...
 Public Key Type : RSA (1.2.840.113549.1.1.1)
 Fingerprint : SHA1 : 
     50 52 0B F1 F4 35 5A C0 F5 1E 73 9C C8 AA 7E 03
     A1 07 51 CB
 Fingerprint : MD5 : 
     3C F4 33 8D 47 96 79 28 6D A0 92 39 6B 88 DA 16
 Fingerprint : SHA256 : 
     82 41 66 29 DD 94 C4 22 C6 2B 1E C3 08 EF 9C 6E
     B6 40 C9 C2 B1 BC 2F FA 8D FD C4 DB 14 90 D2 BE
 Fingerprint : HPKP : 
     8PqRjTnsU3u6nwvNX/RGux9aI7TgJHOtkZYJtYly7vI=
 Extensions
     basicConstraints
         ca = false
         critical
     AuthorityKeyIdentifier
       keyIdentifier:
     28 D0 B2 DD E3 F9 26 06 C9 56 76 5E 17 5E 0A 21
     C4 9A 85 46
       authorityIdentifier:
       authorityCertSerialNumber:
     SubjectKeyIdentifier
       keyIdentifier:
     F0 6A F8 9A 46 C0 76 5A 05 7D AD C4 5B 01 6A 44
     1C CB F2 D7
 Signature Algorithm : SHA256WithRSASignature (1.2.840.113549.1.1.11)
 Value
     A6 D1 5F A9 D4 86 A9 5B C0 90 30 B3 9D 57 40 86
     ...
 Trust Status : Enabled
```
The size of the (private) key associated with the certificate is 2048 bit, as was requested when creating the certificate request. The subject distinguished name corresponds to the value specified for the request, as does the signature algorithm. The "basicConstraints" extension has the attributes "ca = false" and "critical". "ca = false" designates this certificate as a user certificate that cannot be used as a CA certificate to validate other certificates. The validity of the certificate is one year, which is the default when signing and issuing a certificate as CA.

Subject and issuer distinguished names differ, because this is not a self-signed certificate. Correspondingly, the "AuthorityKeyIdentifier" and "SubjectKeyIdentifier" also have different values.