Replacing TLS certificate, key and CA in 389 DS instance

This document (000020983) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 15 SP4
SUSE Linux Enterprise Server 15 SP3

Situation

389 DS instance was created with a self-signed certificate and now it is needed to replace it with a certificate signed by other CA.

Resolution

To replace certificates currently used by 389 DS instance the procedure is the following:

1. Add CA

PEM format will be used, if you have other format, please refer to 'Additional information' section.

Let's inspect the CA to be imported first:

$ openssl x509 -in chained.pem -subject -noout
subject=C = CZ, ST = Prague, L = Prague, O = avocado HashiCorp Vault CA, CN = avocadoHashiCorpVaultCA 2023

Importing the CA certificate via `dsconf':

$ dsconf EXAMPLE security ca-certificate add --file chained.pem --name 'avocadoHashiCorpVaultCA 2023'
Successfully added CA certificate (avocadoHashiCorpVaultCA 2023)

Another inspection via `certutil' will show newly imported CA:

$ certutil -L -d /etc/dirsrv/slapd-EXAMPLE/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Self-Signed-CA                                               CT,,
Server-Cert                                                  u,u,u
avocadoHashiCorpVaultCA 2023                                 CT,,

2. Add Certicate

Let's inspect the certificate to be imported first, same for the private key (checking certificate 'modulus' would help us to see if the key is the right one for the certificate).

$ openssl x509 -in cert.pem -issuer -subject -modulus -noout | fold -w80
issuer=C = CZ, ST = Prague, L = Prague, O = avocado HashiCorp Vault CA, CN = avo
cadoHashiCorpVaultCA 2023
subject=CN = jb154sapqe01.example.com
Modulus=B24AAD3FCCD38C1CFC0F3CDFE4E084D4B63B2867E8D147BC4FCF8D4D8DA471E18021FE05
ED51CF12D14ED451576A496C6CA23EB9D22B41D300692EBDA892EC233C90BF435F2CE8B4977EF0B4
5D4F363F5DFA1A56C3A523B24E7E7D8EE28C58A25B0BB8B7CF2049393874BE2BDCF00D9A8F9A0A86
BC11B8FA945A32467EC1F681018A3652FFD2FF00B257C2B351A84AF57294466368FF95186E5C25D1
93C9AA72D81BB0780B09798470B8E9049A8171116F505F09BE00D89C9725D107640E26CE17AA5B0E
9FA08DFCA23086F779AF70E7EBE94DBC0194142A35E443BC8E58BF04E267F05D8F1CA95F4D98F769
475A39D70024EE00CB42440711CB25B2D8B68545

$ file key.pem ; openssl rsa -in key.pem -check -modulus -noout | fold -w80
key.pem: PEM RSA private key
Modulus=B24AAD3FCCD38C1CFC0F3CDFE4E084D4B63B2867E8D147BC4FCF8D4D8DA471E18021FE05
ED51CF12D14ED451576A496C6CA23EB9D22B41D300692EBDA892EC233C90BF435F2CE8B4977EF0B4
5D4F363F5DFA1A56C3A523B24E7E7D8EE28C58A25B0BB8B7CF2049393874BE2BDCF00D9A8F9A0A86
BC11B8FA945A32467EC1F681018A3652FFD2FF00B257C2B351A84AF57294466368FF95186E5C25D1
93C9AA72D81BB0780B09798470B8E9049A8171116F505F09BE00D89C9725D107640E26CE17AA5B0E
9FA08DFCA23086F779AF70E7EBE94DBC0194142A35E443BC8E58BF04E267F05D8F1CA95F4D98F769
475A39D70024EE00CB42440711CB25B2D8B68545
RSA key ok

We can see our certificate is issued by already imported CA.

If you want to export a current self-signed certificate and the CA, see 'Additional information' section.

Importing the certification via `dsctl' (note that first argument is path to the certificate, then to the key):

$ dsctl EXAMPLE tls import-server-key-cert cert.pem key.pem

Another inspection of 389 DS instance NSS DB with `dsctl' will show us a newly imported certificate issued by our previously imported CA:

$ dsctl EXAMPLE tls show-cert 'Server-Cert' | head -n 13
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6f:d0:ff:8f:da:a4:91:65:1e:71:46:1d:0c:7a:46:29:
            f2:6a:de:a7
        Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
        Issuer: "CN=avocadoHashiCorpVaultCA 2023,O=avocado HashiCorp Vault CA
            ,L=Prague,ST=Prague,C=CZ"
        Validity:
            Not Before: Tue Feb 21 12:36:41 2023
            Not After : Fri Feb 24 12:37:11 2023
        Subject: "CN=jb154sapqe01.example.com"

3. Restarting 389 DS instance to load new TLS configuration

$ dsctl EXAMPLE restart
Instance "EXAMPLE" has been restarted

Live testing of our running 389 DS instance via TCP/IP:

$ : | openssl s_client -connect 127.0.0.1:636 -showcerts 2>/dev/null | \
    awk -v cmd='openssl x509 -noout -text' \
    '/BEGIN/{close(cmd)}; { print | cmd }' 2>/dev/null | head -n 13
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6f:d0:ff:8f:da:a4:91:65:1e:71:46:1d:0c:7a:46:29:f2:6a:de:a7
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = CZ, ST = Prague, L = Prague, O = avocado HashiCorp Vault CA, CN = avocadoHashiCorpVaultCA 2023
        Validity
            Not Before: Feb 21 12:36:41 2023 GMT
            Not After : Feb 24 12:37:11 2023 GMT
        Subject: CN = jb154sapqe01.example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption

Cause

It's very possible that your 389 DS instance was created with a self-signed certification. For example `dscreate create-template' enables this by default:

$ dscreate create-template >(grep 'self_sign_cert ')
# self_sign_cert (bool)
;self_sign_cert = True

(Note that setting `self_sign_cert' to False in an inf answer file used to create an instance via `dscreate from-file' disables TLS security completely in the newly created instance - that is, it does set `nsslapd-security: off'.)

Live inspection of running 389 DS instance can be done via TCP/IP with OpenSSL tools:

$ : | openssl s_client -connect 127.0.0.1:636 -showcerts 2>/dev/null | \
    awk -v cmd='openssl x509 -noout -subject -startdate -enddate -ext subjectAltName' \
        '/BEGIN/{close(cmd)}; { print | cmd }' 2>/dev/null
subject=C = AU, ST = Queensland, L = 389ds, O = testing, GN = 1baf1910-52c9-4cea-b0b0-c7cd9a5a97b1, CN = jb154sapqe01.example.com
notBefore=Feb 21 14:36:07 2023 GMT
notAfter=Feb 21 14:36:07 2025 GMT
X509v3 Subject Alternative Name:
    DNS:jb154sapqe01.example.com
subject=C = AU, ST = Queensland, L = 389ds, O = testing, CN = ssca.389ds.example.com
notBefore=Feb 21 14:36:03 2023 GMT
notAfter=Feb 21 14:36:03 2025 GMT

Or via `dsctl' (for the instance certification) and `dsconf' for the CA:

$ dsctl EXAMPLE tls show-cert 'Server-Cert' | head -n 13
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            00:be:a6:d6:67
        Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
        Issuer: "CN=ssca.389ds.example.com,O=testing,L=389ds,ST=Queensland,C=
            AU"
        Validity:
            Not Before: Tue Feb 21 14:36:07 2023
            Not After : Fri Feb 21 14:36:07 2025
        Subject: "CN=jb154sapqe01.example.com,givenName=1baf1910-52c9-4cea-b0
            b0-c7cd9a5a97b1,O=testing,L=389ds,ST=Queensland,C=AU"

$ dsconf EXAMPLE security ca-certificate list
Certificate Name: Self-Signed-CA
Subject DN: CN=ssca.389ds.example.com,O=testing,L=389ds,ST=Queensland,C=AU
Issuer DN: CN=ssca.389ds.example.com,O=testing,L=389ds,ST=Queensland,C=AU
Expires: 2025-02-21 14:36:03
Trust Flags: CT,,

Practically, NSS DB is used, thus `certutil' can be also used for the inspection:

$ certutil -L -d /etc/dirsrv/slapd-EXAMPLE/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Self-Signed-CA                                               CT,,
Server-Cert                                                  u,u,u

Thus, in case of this 'EXAMPLE' instance, we have 'Self-Signed-CA' CA certificate and 'Server-Cert' certificate. Details about trust attributes can be found in certutil documentation.

Additional Information

Exporting current NSS DB in PKCS#12

Exporting (self-signed certificate and the CA) from 389 DS instance, it is recommended to protect the output file with a passphrase as it includes also a private key (note that NSS DB is protected with a PIN, thus using the PIN):

$ pk12util -o /root/slapd-EXAMPLE.p12 \
    -n 'Server-Cert' -d /etc/dirsrv/slapd-EXAMPLE \
    -k <(awk -F: '{ print $2 }' /etc/dirsrv/slapd-EXAMPLE/pin.txt)

The output file can be inspected with:

$ pk12util -l /root/slapd-EXAMPLE.p12

Extracting certificate and key in PEM from PKCS#12 format

- key

$ openssl pkcs12 -in /root/slapd-EXAMPLE.p12 -nocerts -nodes > newkey.pem

- certificate

$ openssl pkcs12 -in /root/slapd-EXAMPLE.p12 -nokeys > newcert.pem

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.