dogtagpki

#2349 Separated TPS does not automatically receive shared secret from remote TKS
Closed: Fixed Opened by mharmsen.

Closed: Fixed
Reopen Issue

While working on PKI TRAC Ticket #432 - Certificate nickname improvement', a Separated TKS and Separated TPS were installed as two distinct PKI instances.

The following configuration override files were used for TKS:

[DEFAULT]
pki_admin_password=Secret123
pki_client_database_password=Secret123
pki_client_pkcs12_password=Secret123
pki_ds_password=Secret123
pki_security_domain_password=Secret123
# Optionally keep client databases
pki_client_database_purge=False
# Separated TKS instance name and ports
pki_instance_name=pki-tks
pki_http_port=30080
pki_https_port=30443
# Separated TKS instance security domain references
pki_issuing_ca=https://pki.example.com:18443
pki_security_domain_hostname=pki.example.com
pki_security_domain_https_port=18443
pki_security_domain_user=caadmin
[Tomcat]
# Separated TKS Tomcat ports
pki_ajp_port=30009
pki_tomcat_server_port=30005
[TKS]
# Separated TKS instance requires its own PKI Administrator Certificate
pki_import_admin_cert=False

and for TPS:

[DEFAULT]
pki_admin_password=Secret123
pki_client_database_password=Secret123
pki_client_pkcs12_password=Secret123
pki_ds_password=Secret123
pki_security_domain_password=Secret123
# Optionally keep client databases
pki_client_database_purge=False
# Separated TPS instance name and ports
pki_instance_name=pki-tps
pki_http_port=31080
pki_https_port=31443
# Separated TPS instance security domain references
pki_issuing_ca=https://pki.example.com:18443
pki_security_domain_hostname=pki.example.com
pki_security_domain_https_port=18443
pki_security_domain_user=caadmin
[Tomcat]
# Separated TPS Tomcat ports
pki_ajp_port=31009
pki_tomcat_server_port=31005
[TPS]
# Separated TPS instance requires specifying a remote CA
pki_ca_uri=https://pki.example.com:18443
# Separated TPS instance optionally utilizes a remote KRA for server-side keygen
pki_kra_uri=https://pki.example.com:28443
pki_enable_server_side_keygen=True
pki_authdb_basedn=dc=example,dc=com
# Separated TPS instance requires specifying a remote TKS
pki_tks_uri=https://pki.example.com:30443
pki_import_shared_secret=True
# Separated TPS instance requires its own PKI Administrator Certificate
pki_import_admin_cert=False

Although the TPS installed correctly, it was determined that the TPS was not working when tpsclient < format.tst was run against it.

Checking the TKS server NSS databases showed:

# tkstool -L -d /etc/pki/pki-tks/alias
 slot:  NSS User Private Key and Certificate Services
token:  NSS Certificate DB
Enter Password or Pin for "NSS Certificate DB":
    <0> defKeySet-authKey
    <1> TPS-pki.example.com-31443 sharedSecret
    <2> defKeySet-kekKey
    <3> defKeySet-macKey
    <4> defKeySet-encKey

while checking the TPS server NSS database showed:

# tkstool -L -d /etc/pki/pki-tps/alias
 slot:  NSS User Private Key and Certificate Services
token:  NSS Certificate DB
Enter Password or Pin for "NSS Certificate DB":
    tkstool: the specified token is empty

It was believed that setting pki_import_shared_secret=True in the TPS override configuration file should have imported the shared secret from the TKS into the TPS, however, upon closer inspection of the source code, it was noticed that the following imcomplete code in **pki/base/util/src/com/netscape/cmsutil/crypto/CryptoUtil.java ** been commented out since it is not yet ready for use:

    /*
    public static void importSharedSecret(KeyData data) throws EBaseException, NotInitializedException, TokenException,
            NoSuchAlgorithmException, ObjectNotFoundException, InvalidKeyException, InvalidAlgorithmParameterException,
            IOException {
        byte[] wrappedKey = Utils.base64decode(data.getWrappedPrivateData());
        IConfigStore cs = CMS.getConfigStore();
        String subsystemNick = cs.getString("tps.cert.subsystem.nickname");
        String keyNick = cs.getString("conn.tks1.tksSharedSymKeyName", "sharedSecret");
        CryptoManager cm = CryptoManager.getInstance();
        CryptoToken token = cm.getInternalKeyStorageToken();
        KeyManager km = new KeyManager(token);
        if (km.uniqueNamedKeyExists(keyNick)) {
            throw new IOException("Shared secret " + keyNick + " already exists");
        }
        KeyWrapper keyWrap = token.getKeyWrapper(KeyWrapAlgorithm.RSA);
        X509Certificate cert = cm.findCertByNickname(subsystemNick);
        PrivateKey subsystemPrivateKey = cm.findPrivKeyByCert(cert);
        keyWrap.initUnwrap(subsystemPrivateKey, null);
        @SuppressWarnings("unused")
        SymmetricKey unwrapped = keyWrap.unwrapSymmetric(wrappedKey, SymmetricKey.DES,
                SymmetricKey.Usage.DECRYPT, 0);
        // TODO - I have a key - now what to do with it?
        // need to somehow import/label the symkey
    }*/

NOTE: This code may not be used due to recent changes made to symkey in JSS (see PKI TRAC Ticket #801 - Merge pki-symkey into jss).

Initial proposed patch containing revised nicknames
20160602-Fix-default-value-of-pki_cert_chain_nickname.patch

Although this bug has a workaround of manually importing the shared key from the desired TKS, it is my hope that this bug can be fixed in the Dogtag 10.3 timeframe.

Proposed Milestone: 10.3.3

Per discussions in CS/DS meeting of 06/06/2016, either fix this issue or clearly document the workaround: 10.3.3

Still working on this one. It turned out that the code was not easy to get working. One end wraps up the key with a cert and the other end tries to unwrap it with a different cert. Working on a way to allow the client to just send the cert to the server to use to wrap up the shared secret.

TO DO:

When the patch that resolves this bug is applied, the following text must be removed from the section entitled 'Installing a KRA, OCSP, TKS, or TPS in a separate instance' to the 'pki/base/server/man/man8/pkispawn.8' man page:

       If TPS and TKS are installed on separate instances  the  shared  secret
       key  needs to be generated manually in TKS, then manually imported into
       TPS.
       Generate the shared secret key in TKS with the following command:
              tkstool -T -d /var/lib/pki/pki-tomcat/alias -n sharedSecret
       Verify the shared secret key in TKS with the following command:
              tkstool -L -d /var/lib/pki/pki-tomcat/alias
       Once TPS is installed, shutdown TPS instance, then  import  the  shared
       secret key into TPS with the following command:
              tkstool -I -d /var/lib/pki/pki-tomcat/alias -n sharedSecret
       Verify the shared secret key in TPS with the following command:
              tkstool -L -d /var/lib/pki/pki-tomcat/alias
       The  shared secret key nickname should be stored in the following prop‐
       erty in the TPS's CS.cfg:
              conn.tks1.tksSharedSymKeyName=sharedSecret
       Finally, restart the TPS instance.

commit 0f056221d096a30307834265ecd1c527087bb0f7
Author: Jack Magne jmagne@dhcp-16-206.sjc.redhat.com
Date: Mon Jun 13 11:27:59 2016 -0700

Separated TPS does not automatically receive shared secret from remote TKS.

Closing:

Metadata Update from @mharmsen:
- Issue assigned to jmagne
- Issue set to the milestone: 10.3.4

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/2469

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.
Metadata
None
None
None
Normal
defect
None
None
None
Community
None
None
TPS
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.