Your suggested change has been received. Thank you.

close

Suggest A Change

https://thales.na.market.dpondemand.io/docs/dpod/services/kmo….

Thales Logo

All

  • All
back

CipherTrust Manager Administration

Certificate Authority

search

Please Note:

Certificate Authority

A Certificate Authority (CA) acts as the initially trusted shared entity between peers and issues signed certificates to make it possible for each party to trust the other. The CA issues and installs digital certificates and issues certificate signing requests (CSR).

A certificate generally acts as the identity of a server or client and this API can be used to issue server and client certificates for setting up trusted communication channels to the CipherTrust Manager system.

CipherTrust Manager distinguishes between local CAs and external CAs. A local CA can issue signed certificates since the private signing key is stored inside the CipherTrust Manager system. An external CA does not store the private key. Instead an external CA is used as a trusted entity for various interfaces and services inside the system. In this case certificates are issued externally. It is fine to have a mix of both.

The first time a CipherTrust Manager is started, a new local KeySecure root CA is automatically generated. This CA is used to issue initial server certificates for the interfaces available in the system.

An easy way to inspect the certificate chain is to view the certificates in your browser when you connect to the web interface. All interfaces and services will by default trust this CA, meaning that for interfaces that support client authentication, a client certificate, issued from this initial KeySecure root CA, will automatically be trusted by the system. If preferred, it is possible to create new local CAs and/or external CAs and use these instead for the internal interfaces and services.

Many CA operations can be performed via the CipherTrust Manager GUI.

Here are a few basic procedures for creating CAs and issuing certificates using the CLI Tool (ksctl).

Creating a Local CA

When creating a new local CA, it remains pending until signed:

ksctl ca locals create --cn "Test CA" --csr-outfile csrfile

This returns a CSR, the key remains with the CipherTrust Manager. This CSR can be signed by an external CA.

To just self-sign the CA with a one year duration, use the id returned in the call above:

ksctl ca locals self-sign --id 3593c53b-fbeb-4edb-b84d-c85526ae2f83 -x 365

Issuing a signed certificate

CipherTrust Manager can only issue certificates for “local” CAs. To create a certificate, a CSR must first be generated.

For the highest level of security, it is usually best for the CSR to be generated externally to CipherTrust Manager so the private key is never exposed. However, you can also select Download CSR from the pending CA on the GUI as this will not include the private key.

For convenience, CipherTrust Manager can create a CSR and private key for you:

ksctl ca csr -cn "My Client" --csr-outfile csrfile --key-outfile keyfile

Use the following command to add Subject Alternative Names (SAN) values. If multiple values are specified, separate them with comma (optional).

ksctl ca csr -cn "My Client" --csr-outfile csrfile --key-outfile keyfile --dns "thalesgroup.com,thalesgroup2.com" --ips 1.1.1.1

Note

You cannot add SAN in a default web server certificate post-deployment.
Instead, perform the following steps:
1. Generate a new CSR with the SAN fields. Refer to the above command.
2. Issue a new certificate using the generated CSR. Refer to the below command.
3. Update the web interface by uploading this issued certificate and restart the system.

Once you have a CSR, you can have the CipherTrust Manager issue a certificate:

ksctl ca locals certs issue --ca-id 3593c53b-fbeb-4edb-b84d-c85526ae2f83 --csr-infile csrfile -x 700 -o client

Note

It is also possible to create the CSR and the private key using any other software, as this API is stateless and doesn't store anything within CipherTrust Manager.

Note

• When signing the local CA and certificate, duration is set a day (24 hours) before the current date; therefore the notBefore flag also reflects the same date. This is done to handle the multiple time zone differences.
• The certificate duration shouldn't be more than the CA duration. However, if the certificate duration exceeds the CA duration, the certificate duration is automatically set to CA's duration.

Certificate Expiration Check

The CipherTrust Manager inspects the expiration date of the following types of certificates every day, at a preset system time to log the record:

  • Local CA certificates available on CipherTrust Manager

  • Certificate issued by Local CA and available on CipherTrust Manager

  • External CA certificates uploaded to CipherTrust Manager

The CipherTrust Manager then creates list a of certificates based on their expiration date:

  • Certificates whose expiration dates are within 91 days

    This list is logged in the Records section once every week

  • Certificates whose expiration dates are within 7 days

    This list is logged in the Records section once every day

  • Certificates that are already expired

    This list is logged in the Records section once every day

Note

Interface setting such as NAE allows you to upload certificates directly. The CipherTrust Manager does not check the expiration dates of these certificates.

You can also create alarm triggers for these records. For more details, go to Creating Alarm Trigger for Certificate Expiration.

Revoke/Resume Certificate Signed by the Local CA

The CipherTrust Manager allows you to revoke/resume the client/server certificates signed by the local CA. You can also revoke/resume the certificates of intermediate CAs.

In addition, you can:

  • Publish and maintain the Certificate Revocation List (CRL) for the certificates revoked by the local CA.

  • Migrate the revocation status of the certificates from KeySecure Classic to CipherTrust Manager.

  • Resume the revoked certificates.

    Note

    • Revocation of local CA is not supported, only local CA signed certificates can be revoked.
    • You can only resume the certificates revoked with the reason "certificateHold".

** To revoke a certificate signed by local CA**

Syntax


ksctl ca locals certs revoke --ca-id <ca-identifier> --id <cert-identifier> --reason <revocation-reason>

Example Request


ksctl ca locals certs revoke --ca-id localca-f8aabd4f-6459-4cb0-a26a-dfd88129bd5e --id cert-2526ebf8-8ac2-4e3b-8c2c-9752c3da536d --reason certificateHold

Example Response


{
"id": "2526ebf8-8ac2-4e3b-8c2c-9752c3da536d",
"uri": "kylo:kylo:naboo:certs:2526ebf8-8ac2-4e3b-8c2c-9752c3da536d",
"account": "kylo:kylo:admin:accounts:kylo",
"createdAt": "2021-05-10T15:13:08.429514Z",
"updatedAt": "2021-05-12T06:45:05.421753856Z",
"cert": "-----BEGIN CERTIFICATE-----\nMIIEuDCCAqCgAwIBAgIQOivQNtvy1bsD+ZtTiktSbjANBgkqhkiG9w0BAQsFADBa\nMQswCQYDVQQGEwJVUzELMAkGA1UECBMCTUQxEDAOBgNVBAcTB0JlbGNhbXAxEDAO\nBgNVBAoTB0dlbWFsdG8xGjAYBgNVBAMTEUtleVNlY3VyZSBSb290IENBMB4XDTIx\nMDUwOTE1MTMwOFoXDTIzMDUwOTE1MTMwOFowJTEOMAwGA1UEAxMFYWRtaW4xEzAR\nBgoJkiaJk/IsZAEBEwMxMjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB\nAQDf0/l5sDKlmZ940mc3YAmpdEHmAPf6kDZgtqpuN9ftXji65WIHywZ5VN/5YYVD\nREdbs96kAdNMNyec8As0E0lbgirxaW2HFOzVcdfUyh8FnQWq4kAcGBdL19gvdEm6\noZOaX6XlKZq3REfvFXjPg3YkhOvmaiF/9WFoVafCplpgpib3kiijd3m1ZUHP+uxW\nkfJ6ddxMs3Qe3gltfmpnjoHY433rzh2CFr/W5wufRKZWmlu2OBwTKJsixJbcRJR1\n93+XVELt6r7UmrycZjmi3RIMkJ0WC+KpkL0ZetYtXL/7IykRkzlqAwKI4mpyJjAS\n/3yQgJKCdSBz80BzmbnDevQ9AgMBAAGjga4wgaswDgYDVR0PAQH/BAQDAgOIMBMG\nA1UdJQQMMAoGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUl4YP\nF8V39/lnMb8i5iDOPtXjQ4owVQYDVR0fBE4wTDBKoEigRoZEaHR0cDovL2tleXNl\nY3VyZS5sb2NhbC9jcmxzL2Y4YWFiZDRmLTY0NTktNGNiMC1hMjZhLWRmZDg4MTI5\nYmQ1ZS5jcmwwDQYJKoZIhvcNAQELBQADggIBAAYsYXivy9vD+WMqs4ceC+W3O8Tx\nIW/jaCHfWZKXr4fk01n1Mh020T67wIKqQXUoTKgp9U7vmNMd/RKrj1NS19lEh8sm\nHxy7/bvcSDXajw2LpsmIRaWeqYgO0qOTluMQMMnSBiLbdgSAXKEAjRMQQvQfzqUV\neTSPWaWzyFbnfhSEfU0s46Xs61gWTfvwclvB40Xk7HKFTNUP/xPIfLlhT4H9J3Bx\nyrWz5bJY1z6Cx95/gXsQptccmYik+WGY7IJofvNJD8ugc1t6SeVG2aEl8fNiuS5a\np9O6ThUcM3MqHcL0cOlqm9+jzs5j8pUWbJ+7lsDS17Y+uFvHEJN8XGXQLhFf3p/4\nvNgyMAmB9uvC5rbqEsCKUgpxkNa0sm0WflVoIQ1h2ku01yqtG8krma9qr4zy+bML\nO6Zk37Vn1/8pUjGYWHIPhjX6e+/wlRIMufyqKg7M/OHlg0S6eOpaX13tXxYNnaVm\ngN2mKfvmN3W6sMdtCKifRNeTcuF5R7ZRWXKqHp00Y6N2Tk2FyZjgWAxUtg7VnLPW\nRfuQBQ/Jud7zVDWxtftv6nmrV1nlqErPPDnRt3D49AD5lj4+JhdzKz47F094T++8\n+rauAODq6i+FZe/05RwSCB1fqWJ8ja9gwAWaBVXfQpIDIY3KFTC2tZhjUUOii++d\nP6WaJc1NqTcWns8H\n-----END CERTIFICATE-----\n",
"ca": "kylo:kylo:naboo:localca:f8aabd4f-6459-4cb0-a26a-dfd88129bd5e",
"revoked_reason": "certificateHold",
"revoked_at": "2021-05-12T06:45:05.421580648Z",
"state": "revoked",
"sha1Fingerprint": "C5BF83559D11C81ED84D8F7CC15094DA365D775D",
"sha256Fingerprint": "11C91396CB62BA28EDAE07E79681C25276C7B93DBA033DF08DEB13D9FDBE353F",
"sha512Fingerprint": "28C66DAA4775F37B4294964D45BCC9DB8BAD26C24EB4D9370DE6AB3BEF32C4D156D5FC45D98F6201F97F0D5DEBB43BBC6E24A1FE3743F64E5D1F0B9B2B93FCEE",
"serialNumber": "77322715608031240047279766081599394414",
"subject": "/CN=admin",
"issuer": "/C=US/ST=MD/L=Belcamp/O=Gemalto/CN=KeySecure Root CA",
"notBefore": "2021-05-09T15:13:08Z",
"notAfter": "2023-05-09T15:13:08Z"
}

** To resume a certificate signed by local CA**

Syntax


ksctl ca locals certs resume --ca-id <ca-identifier> --id <cert-identifier>

Example Request


ksctl ca locals certs resume --ca-id localca-f8aabd4f-6459-4cb0-a26a-dfd88129bd5e --id cert-2526ebf8-8ac2-4e3b-8c2c-9752c3da536d

Example Response


{
"id": "2526ebf8-8ac2-4e3b-8c2c-9752c3da536d",
"uri": "kylo:kylo:naboo:certs:2526ebf8-8ac2-4e3b-8c2c-9752c3da536d",
"account": "kylo:kylo:admin:accounts:kylo",
"createdAt": "2021-05-10T15:13:08.429514Z",
"updatedAt": "2021-05-12T06:44:54.401005002Z",
"cert": "-----BEGIN CERTIFICATE-----\nMIIEuDCCAqCgAwIBAgIQOivQNtvy1bsD+ZtTiktSbjANBgkqhkiG9w0BAQsFADBa\nMQswCQYDVQQGEwJVUzELMAkGA1UECBMCTUQxEDAOBgNVBAcTB0JlbGNhbXAxEDAO\nBgNVBAoTB0dlbWFsdG8xGjAYBgNVBAMTEUtleVNlY3VyZSBSb290IENBMB4XDTIx\nMDUwOTE1MTMwOFoXDTIzMDUwOTE1MTMwOFowJTEOMAwGA1UEAxMFYWRtaW4xEzAR\nBgoJkiaJk/IsZAEBEwMxMjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB\nAQDf0/l5sDKlmZ940mc3YAmpdEHmAPf6kDZgtqpuN9ftXji65WIHywZ5VN/5YYVD\nREdbs96kAdNMNyec8As0E0lbgirxaW2HFOzVcdfUyh8FnQWq4kAcGBdL19gvdEm6\noZOaX6XlKZq3REfvFXjPg3YkhOvmaiF/9WFoVafCplpgpib3kiijd3m1ZUHP+uxW\nkfJ6ddxMs3Qe3gltfmpnjoHY433rzh2CFr/W5wufRKZWmlu2OBwTKJsixJbcRJR1\n93+XVELt6r7UmrycZjmi3RIMkJ0WC+KpkL0ZetYtXL/7IykRkzlqAwKI4mpyJjAS\n/3yQgJKCdSBz80BzmbnDevQ9AgMBAAGjga4wgaswDgYDVR0PAQH/BAQDAgOIMBMG\nA1UdJQQMMAoGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUl4YP\nF8V39/lnMb8i5iDOPtXjQ4owVQYDVR0fBE4wTDBKoEigRoZEaHR0cDovL2tleXNl\nY3VyZS5sb2NhbC9jcmxzL2Y4YWFiZDRmLTY0NTktNGNiMC1hMjZhLWRmZDg4MTI5\nYmQ1ZS5jcmwwDQYJKoZIhvcNAQELBQADggIBAAYsYXivy9vD+WMqs4ceC+W3O8Tx\nIW/jaCHfWZKXr4fk01n1Mh020T67wIKqQXUoTKgp9U7vmNMd/RKrj1NS19lEh8sm\nHxy7/bvcSDXajw2LpsmIRaWeqYgO0qOTluMQMMnSBiLbdgSAXKEAjRMQQvQfzqUV\neTSPWaWzyFbnfhSEfU0s46Xs61gWTfvwclvB40Xk7HKFTNUP/xPIfLlhT4H9J3Bx\nyrWz5bJY1z6Cx95/gXsQptccmYik+WGY7IJofvNJD8ugc1t6SeVG2aEl8fNiuS5a\np9O6ThUcM3MqHcL0cOlqm9+jzs5j8pUWbJ+7lsDS17Y+uFvHEJN8XGXQLhFf3p/4\nvNgyMAmB9uvC5rbqEsCKUgpxkNa0sm0WflVoIQ1h2ku01yqtG8krma9qr4zy+bML\nO6Zk37Vn1/8pUjGYWHIPhjX6e+/wlRIMufyqKg7M/OHlg0S6eOpaX13tXxYNnaVm\ngN2mKfvmN3W6sMdtCKifRNeTcuF5R7ZRWXKqHp00Y6N2Tk2FyZjgWAxUtg7VnLPW\nRfuQBQ/Jud7zVDWxtftv6nmrV1nlqErPPDnRt3D49AD5lj4+JhdzKz47F094T++8\n+rauAODq6i+FZe/05RwSCB1fqWJ8ja9gwAWaBVXfQpIDIY3KFTC2tZhjUUOii++d\nP6WaJc1NqTcWns8H\n-----END CERTIFICATE-----\n",
"ca": "kylo:kylo:naboo:localca:f8aabd4f-6459-4cb0-a26a-dfd88129bd5e",
"revoked_at": "0001-01-01T00:00:00Z",
"state": "active",
"sha1Fingerprint": "C5BF83559D11C81ED84D8F7CC15094DA365D775D",
"sha256Fingerprint": "11C91396CB62BA28EDAE07E79681C25276C7B93DBA033DF08DEB13D9FDBE353F",
"sha512Fingerprint": "28C66DAA4775F37B4294964D45BCC9DB8BAD26C24EB4D9370DE6AB3BEF32C4D156D5FC45D98F6201F97F0D5DEBB43BBC6E24A1FE3743F64E5D1F0B9B2B93FCEE",
"serialNumber": "77322715608031240047279766081599394414",
"subject": "/CN=admin",
"issuer": "/C=US/ST=MD/L=Belcamp/O=Gemalto/CN=KeySecure Root CA",
"notBefore": "2021-05-09T15:13:08Z",
"notAfter": "2023-05-09T15:13:08Z"
}

Certificate Revocation List (CRL)

CRL is a list of certificates that have been revoked by the CA before their scheduled expiration date and should no longer be trusted.

  • On CipherTrust Manager, when you create a local root CA, one CRL file is created for the CA with the name <local_ca_id>.crl.

  • It is mandatory to pass the valid DNS names while creating local root CA to ensure that the CRL URL is accessible. If DNS names are not provided, the default name keysecure.local is used.

  • When a new certificate is issued by the local root ca, the certificate contains the URL of the CRL. You can check the URL of the CRL in the certificate under CRL Distribution Points by decoding it and can download the CRL file from the URL.

    Example: OpenSSL command to decode and check the URL of the CRL:

    
openssl x509 -in intermediate/certs/bob2@example.com.cert.pem -noout -text
X509v3 CRL Distribution Points:
Full Name:
URI:http://keysecure.local/1d073d93-b156-49ee-8533-e338953fc6d9.crl

Steps to download and decode the CRL

  1. Download the CRL from the URL and decode it to check the revocation list.

    
openssl crl -in 1d073d93-b156-49ee-8533-e338953fc6d9.crl.crl -noout -text

  2. After decode, you can see the list of revoked certificates. It contains serial numbers of the revoked certificates. The serial numbers are in hex format; whereas CipherTrust Manager stores the serial numbers in decimal format.
    Therefore, to convert the serial number to decimal format, run:

    echo "ibase=16; <hex_serial_number>" | bc

Creating an external CA

To create an external CA you just need to upload the PEM-formatted certificate file:

ksctl ca externals upload --cert-infile mycert.pem

Verifying Revocation Status of Client Certificates

The CipherTrust Manager can be configured to verify the revocation status of client certificate presented to NAE or KMIP interface before establishing a connection with the client.

To configure the CipherTrust Manager for inspecting the client certificate revocation status:

A certificate contains an OCSP responder URL and a Certificate Revocation List (CRL) URL, which are used for verifying the revocation status of the certificate.

Note

An LDAP URL is not supported, that is, if the CRL or OCSP URL begins with ldap://, the CipherTrust Manager skips that URL.

Let's understand how CipherTrust Manager verifies the revocation status of a certificate and permits/drops connection requests in such cases:

Verifying revocation status

CipherTrust Manager looks the client certificate for OCSP responder URL and CRL URL.

  1. If OCSP URL is present

    CipherTrust Manager accesses this URL to verify the revocation status of the Client Certificate.

    Note

    • The certificate to be verified must contain the URL of the certificate issuer(CA). The issuer certificate should be specified using the AIA extension of X.509. The issuer URL should be a http URL and must be accessible.

    • If the issuer URL is not specified in the certificate, the certificate revocation check "Soft Fails" and the connection is created.

    1. If OCSP URL is accessible, the status of certificate gets verified successfully, and CipherTrust Manager allows/drops connection request accordingly.

    2. If OCSP URL is not accessible due to any reason, CipherTrust Manager considers the situation as a "Soft Fail". It allows the connection to establish, but reports a warning. This warning audit log and its details can be viewed in the Records.

  2. If OCSP URL is not present, but CRL URL is present

    CipherTrust Manager verifies the status of certificate using the CRL, and allows/drops connection request accordingly.

    1. If CRL URL is accessible, the status of certificate gets verified successfully, and CipherTrust Manager allows/drops connection request accordingly.

    2. If CRL URL is not accessible due to any reason, CipherTrust Manager considers the situation as a "Soft Fail". It allows the connection to establish, but reports a warning. This warning audit log and its details can be viewed in the Records.

  3. If both OCSP URL and CRL URL are not present

    CipherTrust Manager considers the client certificate to be signed by its local CA, and allows the connection to establish.

    Note

    In any case, if the certificate is found to be revoked, CipherTrust Manager drops the connection request and logs it in Records.

OCSP and CRL Caching

As stated above, verifying the revocation status of a certificate involves establishing a connection with the URL (OCSP or CRL) present in the certificate, and verifying its revocation status. Once the revocation status of a certificate is verified, CipherTrust Manager stores this information for some preset time.

Let's understand how long this information is stored in and how it is used in this time frame:

  • For OCSP method

    After successfully connecting to the OCSP URL, CipherTrust Manager stores the revocation status of the client certificate for a duration of 5 minutes.

    • If CipherTrust Manager receives another connection request from the same client within 5 minutes of a previously successful connection, then CipherTrust Manager refers to the cached revocation status value to verify its revocation status.

    • If CipherTrust Manager recieves another connection request from the same client after 5 minutes of a previously successful connection, then CipherTrust Manager verifies its revocation status through the OCSP URL again.

  • For CRL method

    Each CA promises to update its CRL at the day and time specified in the Next Update field for that CA. While performing a certificate revocation check, the CipherTrust Manager inspects the Next Update value for the CRL associated with each CA on the CipherTrust Manager.

    • If the Next Update value for that CRL is in the past, the CipherTrust Manager attempts to connect to the CRL distribution point (CDP) for the CA to download the updated CRL.

    • If the Next Update value for that CRL is in the future, the CipherTrust Manager waits until that specified time to attempt to connect to the CDP and download the updated CRL.

Enabling/Disabling Certificate Revocation Check

The Certificate Revocation Check is enabled by default. You can enable or disable the certification revocation Check using:

  • API playground

    Refer to "Properties" section (/v1/configs/properties).

  • CLI tool (ksctl)

    Refer the following examples:

    • Command to enable Certificate Revocation Check

      ksctl properties modify -n ENABLE_CERT_REV_CHECK -p true

    • Command to disable Certificate Revocation Check

      ksctl properties modify -n ENABLE_CERT_REV_CHECK -p false

    • Available Flags:

      FlagsInput TypeDescription
      -h, --helpnot applicableCommand help
      -n, --namestringName of the system configuration
      -p, --valuestringValue to be set for the system configuration

Getting the Fingerprint of the CA Certificate

The fingerprint of the old CA certificate that was used to register the client with the CipherTrust Manager is needed when re registering a client. A CipherTrust Manager administrator can provide you the fingerprint.

Fingerprint of the CA certificate can be viewed on the GUI or the API playground.

On the API Playground

To get the fingerprint of a CA certificate:

  1. Acquire an authorization token.

  2. In the left pane of the API playground, click Certificate Authority.

  3. Under Certificate Authority, click Get local CA. The Get section of the API playground is displayed in the right pane.

  4. Click id in /v1/ca/local-cas/{id}.

  5. Enter id of the local CA in the text box.

  6. Click GET. Details of the CA including fingerprints are displayed in the output. Only sha256Fingerprint and sha512Fingerprint are supported for reregistration.

  7. Copy the desired fingerprint. This fingerprint will be used when re-registering clients.

Similarly, you can get fingerprint of external CA certificates.

On the GUI

To get the fingerprint of a CA certificate:

  1. Log on to the CipherTrust Manager as administrator.

  2. In the left pane, click CA > Local. The list of available CAs is displayed.

  3. Click the ellipsis icon corresponding to the CA.

  4. Click Details. Details of the CA including fingerprints are displayed. Only sha256Fingerprint and sha512Fingerprint are supported for reregistration.

  5. Copy the desired fingerprint. This fingerprint will be used when re-registering clients.

Similarly, you can get fingerprint of external CA certificates.

Managing Usage of Certificate Authority (CA)

You can manage the usage of CA on individual CipherTrust Manager domains. The CipherTrust Manager supports user and client authentication.

  • Client authentication: If enabled, the certificates signed by the CA can be used for client authentication in that domain.

  • User authentication: If enabled, the certificates signed by the CA can be used for user authentication in that domain.

If authentication is disabled, the CipherTrust Manager domain does not trust the CA for respective authentication mechanisms, and the certificates are rejected even if valid.

Updating Usage of a Local CA

To update usage of a local CA, run:

Syntax

ksctl ca locals update --id <ca-identifier> --allow-user-authentication <true|false> --allow-client-authentication <true|false>

Example Request

ksctl ca locals update --id e66d047a-2f67-48bf-bcac-862ac773e12a --allow-user-authentication true --allow-client-authentication false

Example Response

{
    "id": "09e3feb5-7c37-4345-9f05-14a95eb4acd9",
    "uri": "kylo:kylo:naboo:localca:09e3feb5-7c37-4345-9f05-14a95eb4acd9",
    "account": "kylo:kylo:admin:accounts:kylo",
    "createdAt": "2022-01-04T16:55:08.995526Z",
    "updatedAt": "2022-01-05T07:31:10.468173266Z",
    "name": "admin",
    "state": "active",
    "csr": "",
    "cert": "-----BEGIN CERTIFICATE-----\nMIIBoTCCASegAwIBAgIQLyw13lVuY5/+BbOYhPfRpjAKBggqhkjOPQQDAzASMRAw\nDgYDVQQDEwdhZG1pbkNBMB4XDTIyMDEwMzE2NTUxMloXDTIzMDEwMzE2NTUxMlow\nEjEQMA4GA1UEAxMHYWRtaW5DQTB2MBAGByqGSM49AgEGBSuBBAAiA2IABMhbWYui\neU0/VVZU0bsD6FWt3xGaBWaGrC2BS6EH+YcacosTm0SMWJSYHhN8YqxF8eMmTF1y\np7tTSRXo89xYqDZK/wMmOjv55l1yhwV+82o8d1y2Q9obkhgXb39JaxLAlaNCMEAw\nDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFIIBQfXX\nu5bdGlOjynb7aL4Leq81MAoGCCqGSM49BAMDA2gAMGUCMQD+aEg5pq3VM78Pp5F0\nJEurbY23XoKwixe23IKUhYBTfdpvaDUZGMtV6c7zIfUa2mMCMBN4Nkc6qva1cHxo\nFbsmjX42K8fukNqzm39w8vM4o+lhnb5J4bRyghbD/Ej67F6Myw==\n-----END CERTIFICATE-----\n",
    "serialNumber": "62703269446467328287939974236420428198",
    "subject": "/CN=adminCA",
    "issuer": "/CN=adminCA",
    "notBefore": "2022-01-03T16:55:12Z",
    "notAfter": "2023-01-03T16:55:12Z",
    "sha1Fingerprint": "B3673DFB030A894EF71A71C0C382E78455C1DA84",
    "sha256Fingerprint": "0242266C65ECA9BB893A75EC425A107CCC92C0BEED8224AD87A3A64E9E077739",
    "sha512Fingerprint": "4B20E210A6FE04D5A086346E809076A17C47873D29F1DC071308121BAF2D2AD9C516726E48364281A15224CFA0365B8AFED34B61D8C109DEDBDF4AB365BBF744",
    "purpose": {
        "client_authentication": "Disabled",
        "user_authentication": "Enabled"
    }
}

Updating Usage of an External CA

To update usage of an external CA, run:

Syntax

ksctl ca externals update --id <ca-identifier> --allow-user-authentication <true|false> --allow-client-authentication <true|false>

Example Request

ksctl ca externals update --id 5cb55f29-2749-4960-a912-98aeff6accda --allow-user-authentication true --allow-client-authentication false

Example Response

{
    "id": "f029ff14-9f27-4015-8609-23f41b6de898",
    "uri": "kylo:kylo:naboo:external_ca:f029ff14-9f27-4015-8609-23f41b6de898",
    "account": "kylo:kylo:admin:accounts:kylo",
    "createdAt": "2022-01-04T16:57:34.723799Z",
    "updatedAt": "2022-01-05T07:32:10.243282197Z",
    "name": "1234",
    "cert": "-----BEGIN CERTIFICATE-----\nMIIBoTCCASegAwIBAgIQLyw13lVuY5/+BbOYhPfRpjAKBggqhkjOPQQDAzASMRAw\nDgYDVQQDEwdhZG1pbkNBMB4XDTIyMDEwMzE2NTUxMloXDTIzMDEwMzE2NTUxMlow\nEjEQMA4GA1UEAxMHYWRtaW5DQTB2MBAGByqGSM49AgEGBSuBBAAiA2IABMhbWYui\neU0/VVZU0bsD6FWt3xGaBWaGrC2BS6EH+YcacosTm0SMWJSYHhN8YqxF8eMmTF1y\np7tTSRXo89xYqDZK/wMmOjv55l1yhwV+82o8d1y2Q9obkhgXb39JaxLAlaNCMEAw\nDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFIIBQfXX\nu5bdGlOjynb7aL4Leq81MAoGCCqGSM49BAMDA2gAMGUCMQD+aEg5pq3VM78Pp5F0\nJEurbY23XoKwixe23IKUhYBTfdpvaDUZGMtV6c7zIfUa2mMCMBN4Nkc6qva1cHxo\nFbsmjX42K8fukNqzm39w8vM4o+lhnb5J4bRyghbD/Ej67F6Myw==\n-----END CERTIFICATE-----",
    "purpose": {
    "client_authentication": "Disabled",
    "user_authentication": "Enabled"
    },
    "serialNumber": "62703269446467328287939974236420428198",
    "subject": "/CN=adminCA",
    "issuer": "/CN=adminCA",
    "notBefore": "2022-01-03T16:55:12Z",
    "notAfter": "2023-01-03T16:55:12Z",
    "sha1Fingerprint": "B3673DFB030A894EF71A71C0C382E78455C1DA84",
    "sha256Fingerprint": "0242266C65ECA9BB893A75EC425A107CCC92C0BEED8224AD87A3A64E9E077739",
    "sha512Fingerprint": "4B20E210A6FE04D5A086346E809076A17C47873D29F1DC071308121BAF2D2AD9C516726E48364281A15224CFA0365B8AFED34B61D8C109DEDBDF4AB365BBF744"
}

Certificate Format in REST-API and UI

If you are uploading certificates using the REST API, certificates are encoded in a JSON string and have \n characters to indicate line endings. CipherTrust Manager's UI web console does not have these characters, so it's easiest to remain in the same interface for certificate operations, and/or pass in and export certificates using a file instead of a pasted string wherever possible. If you are copy-pasting certificate strings between the UI and other interfaces, you must re-encode the certificate strings.

  • To change PEM-encoded strings to JSON, use echo $v | jq -R --slurp where $v is a variable for the string. This is needed to format certificates in the UI to REST API format.

  • To change JSON encoded strings to PEM, use echo $v | /usr/local/bin/jq -r, where $v is a variable for the string.This is needed to format certificates from REST API to the UI format.

On this page