Tectia

Configuring PKI Settings for CA

Tectia Manager has a preconfigured Internal CA (certification authority) which is ready to be used in server certificate enrollment and authentication.

The CA-related configuration options for Internal and External CA Settings are defined in Settings → PKI Settings. Configuring the CA settings requires superuser administrator rights.

Under Settings → PKI Settings, there is a hierarchical menu tree. The first tree item, Internal CAs, contains the settings for the automatically created setup Internal Root CA. The other category is for external CAs and their automatic and manual PKCS#10 enrollment.

The PKI settings view

Figure 9.2. The PKI settings view

For the Internal Root CA, you can create cross-certificates by signing requests in this view: Settings → PKI settings → Sign cross certificate request.

You can also import existing CA certificates to Tectia Manager. Select Settings → PKI settings → Import new CA certificate and copy the CA certificate or upload the certificate file. The imported certificate is expected to be in PEM or plain 64-bit format.

Importing a CA certificate

Figure 9.3. Importing a CA certificate

Internal CA Settings

Select the Internal Root CA entry to edit the PKI settings of the setup Internal CA. Configuration is divided into several tabbed controls as follows.

General - Internal CA settings

Contains the generic CA specific parameters.

Name

In case of an internal CA, contains only the CA symbolic name (different than the subject name in the CA certificate). The name is used in the Tectia Manager administration interface only.

CA certificate Validity period

The validity period of the Internal CA certificate itself can be set when a new CA instance is created, but it cannot be changed afterwards.

Automatic CA Certificate Renewal

The default validity period for internal CAs is five years. To keep the internal public-key infrastructure (PKI) functional for longer periods, the internal CAs need to be renewed before their certificates expire.

To configure Tectia Manager to renew the CA certificates automatically before they expire, select Settings → PKI settings and select the relevant Internal CA to edit, or click Add new. Go to the Automatic CA certificate renewal tab.

Configuring automatic renewal of CA certificates

Figure 9.4. Configuring automatic renewal of CA certificates

CA Certificate renewal offset from expiration

The time offset defining how much before the CA certificate expiry the CA renewal will be initiated. The default is six months.

Required PKI config updates (%) before activating a renewed CA certificate

During the CA certificate renewal all relevant client and server configurations are updated with the new CA certificate to enable server certificate and host-based authentication to work flawlessly after the renewal. This field indicates the required percentage of successfully updated and deployed configurations before certificate enrollment using the new CA certificate begins. The default is 90%.

Setting this field to 90%, for instance, means that after the CA certificate renewal, in the worst case, on at most 10% of all managed hosts the server certificate or the host-based authentication may break and require updating the configurations manually with the new CA certificate. The motivation is that a significant part of the managed hosts may be off line for a long period of time during the CA certificate renewal, thus stalling the renewal unnecessarily, in the worst case, postponing the start of enrollment using the key in the new CA certificate until after the old one has expired. This field provides a trade off to prevent this from happening.

Host Certificate
Configuring Host certificate settings of Internal Root CA

Figure 9.5. Configuring Host certificate settings of Internal Root CA

Host certificate validity period

Validity period for issued host certificates. The default is 3 months.

Host certificate renew marginal

A time marginal for certificate renewal. For example, if the marginal is 15 days, the system will try to renew all host certificates issued by this CA 15 days before their expiration.

Certificate signature algorithm

Algorithm for certificate signing. SHA-1 is the default, but also SHA-256 support is available.

CRL - Certificate Revocation List
Configuring CRL settings of Internal Root CA

Figure 9.6. Configuring CRL settings of Internal Root CA

CRL update period

A new CRL is generated once per period, in general. Revocations cause also unscheduled CRL generations.

CRL next update marginal

A time marginal added to the nextUpdate time in the issued CRL. Clients usually trust a CRL only to its nextUpdate time after which they will try to fetch a new CRL. Making the CRL validity longer by adjusting nextUpdate will provide extra marginal for clients with inaccurate time settings and will allow longer downtime for the CA itself, if needed. The downside is that some caching clients might not fetch a new CRL when the previous one is still valid. This reduces the propagation speed for revocation information.

Example: A CA issues a new CRL once per hour but has the next update marginal set to 24 hours. This means that the CA will issue a new CRL once per hour with nextUpdate set to 25 hours in future. Now if a certificate is revoked 2 hours later, it will be added to all newly issued CRLs but if a client still uses the original CRL (which is still valid for 23 hours) it will not reject that certificate.

However, if the Management Server machine has to be shut down for maintenance (perhaps quite quickly) it will allow for at least 24 hours of downtime until CRL checks will start to fail. Changing the marginal dynamically is also possible but then administrators have to wait until a new, longer CRL has been propagated to all clients.

CRL signature algorithm

Algorithm used in CRL signing. The default is SHA-1, but also SHA-256 support is available.

CRL publishing methods

A list of CRL publishing (distribution) methods. The default is internal HTTP based method which uses the Manager HTTP server in port 80. The operator can also add one or more external publishing methods by clicking the Add button.

External CRL publishing uses arbitrary commands to publish the CRL and thus has two parameters:

Command line

Command to run. Command line is processed for special fields before it is passed to the operating system and executed:

${crl}

Tectia Manager writes the new CRL into a temporary file and the ${crl} field in the command line is replaced with the file name.

${dpid}

As the internal CA uses multiple dynamically created CRL distribution points, the CRLs must usually be distributed from several separate locations. The CRL distribution point ID number is used for that purpose. The field is replaced with the ID number directly.

${crlnumber}

The sequence number of CRL. Normally not needed in publishing.

${cacertificate}

The CA certificate is written to a temporary file and the field on the command line is replaced with the file name. Some commonly used CRL distribution methods also distribute the CA certificate in the same place or the CRL distribution location can be derived from the CA subject name (as in LDAP).

${uri}

The URI which will be encoded to issued certificates. Can be useful with a publishing script but usually not needed. The field is replaced with the URI directly.

URL

The URL which will be encoded to issued certificates. As in command line, this should also contain the ${dpid} field to identify the different distribution points.

Note that the CA can only have one internal HTTP CRL distribution point entry in the configuration but it can also be removed. CA has to have at least one CRL distribution point entry on some type.

If an internal HTTP CRL distribution point is used, the issued certificates will contain a CRL distribution point extension with the following URL format:

http://hostname:80/internal-ca/crldp${dpid}.crl
[Note]Note

In the URL, hostname is taken from Tectia Manager configuration file server-config.dat. If the host name is changed, the system does not automatically issue a new CRL on startup. All previously issued certificates will have invalid CRL distribution point extensions and probably require re-enrollment.

External CA Automatic Enrollment

Use the following configuration to enroll external CAs automatically. The settings are divided into several tabbed views.

General - Certificate Authority Settings
Name

The symbolic name for internal use in the Tectia Manager administration interface.

CA certificate

Binary field to contain the CA certificate for both enrollment purposes and for host configuration deployment. Use the Upload button to upload a certificate in PEM, base64, or binary format. After a CA certificate has been uploaded it can be changed only by first deleting it.

Host Certificate Parameters
Requested host certificate validity period

The validity period set in request. However, the external CA will probably reset the validity period according to its own policy.

Certificate renew marginal

Same as in the internal CA case, except that No automatic renewal is also an option.

Enrollment Parameters
CA address

CA address. Usable in enrollment scripts.

Enrollment command line

Command line uses replaceable fields. Some larger field values are written to temporary files and the field itself is replaced with a file name. The available fields are:

${pkcs10}

The PKCS#10 request in PEM format. Writes the request to a temporary file.

${pkcs10-bin}

PKCS#10 request in binary format, written to a temporary file.

${ca-cert}

CA certificate written to a temporary file in binary format.

${ca-address}

CA address field from the configuration.

${ca-subject-name}

Subject name from the CA certificate.

${certificate}

Old certificate. Only in renew and revoke.

${subject-name}

Subject name of the old certificate. Only in renew and revoke.

${issuer-name}

Issuer name of the old certificate. Only in renew and revoke.

${serial-number}

Serial number of the old certificate. Only in renew and revoke.

${reference-number}

If a valid PSK has been provided for host, its reference number part is given as command-line parameter.

${psk}

If a valid PSK has been provided for host, its secret part is given as a command-line parameter.

Polling command line

Similar to enrollment command line. The same options are usable and in addition the polling state (if any) can be given.

${pollstate}

The polling state data returned by a previous enrollment command is written to a temporary file.

Revocation command line

Revocation command line.

Poll interval in seconds

Polling interval in seconds.

Requires PSK

If enabled, each host requires a separate pre-shared key (PSK) for enrollment. This means that enrollment job is put on hold until the operator provides a PSK.

External CA Manual Enrollment

Use the following configuration settings to enroll external CAs manually. The settings are divided into several tabbed views.

General - Certificate authority settings
Name

The symbolic name for internal use in the Tectia Manager administration interface.

CA certificate

Binary field to contain the CA certificate for both enrollment and host configuration deployment purposes. Use the Upload button to upload a certificate in PEM, base64, or binary format. After a CA certificate has been uploaded it can be changed only by first deleting it.

Host Certificate Parameters
Requested host certificate validity period

Validity period set in the request. However the external CA usually resets the validity period according to its own policy.

Certificate renew marginal

Same as in the internal CA case, except that No automatic renewal is also an option.

Enrollment Parameters
CA address

CA address. Currently not used; only a reminder for the operator.

Enrollment batch file size limit

Maximum number of requests in batch file when it is downloaded.

Use directory polling

Enable file-based request processing. Tectia Manager writes requests to a specific directory ('request directory') as separate PEM-encoded PKCS#10 files. When a CA operator (or an automated process) has enrolled a certificate, it is written to a second directory ('incoming'). Tectia Manager scans the incoming directory periodically and automatically imports any valid certificates it finds there. Polling is done once per minute.

Request directory path

Request directory for directory polling. Pending PKCS#10 requests will be written here in PEM format. Operator (or other request processing party) can either remove the request themselves or leave it there in which case the system will remove it when the corresponding certificate is received (or removed as rejected).

Incoming directory path

Directory for enrolled certificates. Polled once per minute. Any readable file will be decoded and inserted into the database provided that a matching open request can be found. Accepts certificates either in binary, PEM, or plain base64 formats.

Remove old unprocessed requests

Automatically closes requests older than the selected ones. Removes them from both the database and the request directory.

Requires PSK

If enabled, each host requires a separate pre-shared key (PSK) for enrollment. This means that enrollment job is put on hold until the operator provides a PSK.

Apart from the configuration itself, the most important parts of manual PKCS#10 handling are request queue download and certificate import. These options are located on the PKI configuration main page.

The Download request queue button allows the operator to download a batch of pending requests in PEM-encoded PKCS#10 format. Multiple requests are returned in a single file, separated with normal PEM headers.

After the operator has downloaded the queue, the requests have been transferred to external CA, and they have been issued as certificates, the issued certificates must be imported back to Tectia Manager. This is done by clicking the Upload certificates button. The operator then uploads one certificate at a time in binary, plain base64, or PEM format. Alternatively all issued certificates can be imported simultaneously in a single file if they are in PEM format, separated by normal PEM headers.

When an issued certificate is imported, the corresponding request will be closed and the enrollment for that host continues with the certificate installation phase. Before the certificates are imported, the request queue can be downloaded multiple times.

If the request queue contains older requests which will not be issued, the queue can be cleared either totally or by rejecting the old requests.