Configure certificates and policies

A certificate uses a key policy to create, import, or reuse its private key and a renewal policy to control renewal. Configure the issuer and credentials first, then add the policies and certificate. Open your service in CERTCOM and replace the sample names and domain names with your own.

Add a key policy

Create a named key policy before adding a certificate that uses it. This example selects generation of a 2048-bit RSA key and then displays the saved policy:

ADD KEY-POLICY server-rsa, SOURCE GENERATE, ALGORITHM RSA, SIZE 2048
INFO KEY-POLICY server-rsa, DETAIL

Add a renewal policy

A renewal policy sets when automatic renewal becomes due and how retries and deployment are handled. This example begins renewal 15 days before expiry, enables ARI and manual renewal, and requests deployment after successful renewal:

ADD RENEWAL-POLICY standard-renewal, RENEW-BEFORE 15d, &
  USE-ARI ON, RETRY-INTERVAL 1h, MAX-RETRIES 12, &
  RANDOM-DELAY 30m, MANUAL-RENEW ON, &
  DEPLOY-AFTER-RENEW ON

RENEW-BEFORE, RETRY-INTERVAL, and RANDOM-DELAY accept unsigned whole seconds or a single S, M, H, or D suffix for seconds, minutes, hours, or days. Suffixes are case-insensitive: 3600, 3600s, 60m, and 1H specify the same duration. The converted value must be at most 4294967295 seconds. Signs, decimals, embedded spaces, compound values such as 1h30m, and other suffixes are rejected. An invalid duration reports the parameter name and leaves the policy unchanged.

ADD requires RENEW-BEFORE. If omitted, RETRY-INTERVAL defaults to 1h and RANDOM-DELAY to 15m. ALTER preserves omitted values. INFO reports readable units, such as 15 days, 1 hour, 30 minutes, or 0 seconds, choosing the largest unit that divides the stored value exactly.

Named INFO RENEWAL-POLICY reports Use ARI as ON or OFF. Certificate LINKS uses the same readable Renew Before duration as renewal-policy INFO.

Add a managed certificate

Add a certificate to specify the domain names it will cover and the issuer and policies it will use. This example adds web-server with two DNS names, then displays its configuration and status. Adding a certificate does not issue its first version:

ADD CERTIFICATE web-server, ISSUER public-acme, &
  RENEWAL-POLICY standard-renewal, KEY-POLICY server-rsa, &
  SUBJECT CN=server.example.com, &
  SAN (DNS:server.example.com,DNS:server-alias.example.com)
INFO CERTIFICATE web-server, DETAIL
STATUS CERTIFICATE web-server, DETAIL

The certificate has no active version until issuance succeeds. If you already have a certificate installed, follow Adopt an existing certificate installation.

For a single DNS name, SUBJECT server.example.com stores CN=server.example.com. On ADD, omitting SAN creates DNS:server.example.com from the single DNS common name. A comma-separated distinguished name, such as 'CN=server.example.com,O=Example', is also accepted. Supply SAN explicitly when the subject has no single DNS common name, including an IP-address common name or multiple common names. SUBJECT attribute names accept any case: cn, CN and cN are equivalent, as are commonname and commonName. Recognized names are stored with their standard spelling; attribute values retain their case. For example, 'o=Example Company,cN=Server.example.com' stores 'O=Example Company,CN=Server.example.com'.

SAN prefixes DNS, IP, URI and email also accept any case and are stored as DNS:, IP:, URI: and email:. Values retain their case, including URI paths and email local parts. For example, SAN (uRi:https://example.com/Case) preserves the path /Case. Bare DNS names remain accepted. ALTER preserves the SAN list when SAN is omitted, even when SUBJECT changes. Escaped separators and multi-valued RDNs are unsupported.

Adopt an existing certificate installation

ADOPT CERTIFICATE creates a managed certificate, stores the imported material as its current version, and creates the named source target. The managed certificate and target must not already exist. Configure the referenced issuer, renewal policy, key policy, and any passphrase credential before starting adoption.

Before saving the imported certificate, ActivCERT confirms that the private key matches it and validates the certificate chain. It records the subject when present, subject alternative names, fingerprint, serial number, validity period, public-key details, and the certificate authority that signed it. A certificate may have an empty subject when it contains at least one subject alternative name.

ISSUER selects the certificate authority that ActivCERT will use for future renewals. That issuer may differ from the authority that signed the imported certificate; INFO CERTIFICATE <certificate-name>, VERSION <number>, DETAIL shows the original Signing Issuer. RENEWAL-POLICY controls when renewal is due, and KEY-POLICY controls whether renewal reuses or replaces the imported private key.

An imported version has an Issuance Source of EXTERNAL. Its first renewal through an ACME issuer starts a normal certificate order. After ActivCERT obtains that renewed version, later renewals can identify the preceding certificate when they use the same ACME service and account. Changing the ACME service or account also starts a normal order.

Adopt separate PEM files

Use PEM-SEPARATE with EDIT or STREAM files. CERT-FILE and KEY-FILE are required. Supply CHAIN-FILE when the installation includes intermediate certificates:

FULLCHAIN-FILE is an optional destination for later deployment. It need not exist during adoption and is not read as imported source material. Adoption reads CERT-FILE, KEY-FILE, and any supplied CHAIN-FILE, without rewriting them. The source target uses REPLACE-OR-CREATE for later deployments, so an absent optional full-chain output can be created then.

ADOPT CERTIFICATE legacy-web, SOURCE FILE, &
  TARGET legacy-source, ISSUER public-acme, &
  RENEWAL-POLICY standard-renewal, KEY-POLICY server-rsa, &
  FORMAT PEM-SEPARATE, FILE-TYPE EDIT, &
  CERT-FILE $DATA.CERTS.WEBCERT, KEY-FILE $DATA.CERTS.WEBKEY, &
  CHAIN-FILE $DATA.CERTS.WEBCHAIN, &
  FULLCHAIN-FILE $DATA.CERTS.WEBFULL, WAIT

Adopt a PEM full chain

Use PEM-FULLCHAIN with EDIT or STREAM files. FULLCHAIN-FILE must contain the leaf certificate followed by its chain, and KEY-FILE must contain the matching private key:

ADOPT CERTIFICATE legacy-fullchain, SOURCE FILE, &
  TARGET legacy-fullchain-source, ISSUER public-acme, &
  RENEWAL-POLICY standard-renewal, KEY-POLICY server-rsa, &
  FORMAT PEM-FULLCHAIN, FILE-TYPE STREAM, &
  FULLCHAIN-FILE $DATA.CERTS.WEBFULL, &
  KEY-FILE $DATA.CERTS.WEBKEY, WAIT

Adopt a PKCS12 archive

Use PKCS12 with a BINARY file. PASSPHRASE names an enabled PKCS12-PASSPHRASE credential; the command never contains the clear-text passphrase. Use NO-PASSPHRASE only when the archive has an empty passphrase:

ADOPT CERTIFICATE legacy-p12, SOURCE FILE, &
  TARGET legacy-p12-source, ISSUER public-acme, &
  RENEWAL-POLICY standard-renewal, KEY-POLICY server-rsa, &
  FORMAT PKCS12, FILE-TYPE BINARY, &
  PKCS12-FILE $DATA.CERTS.WEBP12, &
  PASSPHRASE p12-passphrase, WAIT

Adopt from LightWave

For LightWave Server or LightWave Client, supply the fully qualified LWSCOM or LWCCOM program file, the existing LightWave certificate specification, and an enabled PKCS12-PASSPHRASE credential. COMMON-NAME sets the name shown in ActivCERT. IMPORT-CHAIN and EXPORT-CHAIN default to ON and control whether later LightWave operations include the certificate chain:

ADOPT CERTIFICATE legacy-lightwave, SOURCE LIGHTWAVE, &
  TARGET legacy-lightwave-source, ISSUER public-acme, &
  RENEWAL-POLICY standard-renewal, KEY-POLICY server-rsa, &
  PROGRAM-FILE $DATA.LWS.LWSCOM, &
  CERT-SPEC server.example.com, PASSPHRASE p12-passphrase, &
  COMMON-NAME server.example.com, &
  IMPORT-CHAIN ON, EXPORT-CHAIN ON, WAIT

Confirm completion and recover interrupted work

WAIT waits for adoption to finish. On success, CERTCOM displays SUCCESS, the Task Handle, and the imported Certificate Version. The task type is IMPORT. Without WAIT, CERTCOM displays SUBMITTED and the Task Handle; use these commands to check its progress:

INFO TASK <task-handle>
STATUS TASK <task-handle>
WAIT TASK <task-handle>, TIMEOUT 300
INFO EVENT *, RECENT 20

Adoption accepts a certificate that is currently valid. It rejects an expired certificate and a certificate whose validity period has not started. A valid certificate inside the renewal window is imported and marked due according to the selected renewal policy. When the scheduler is active, normal renewal processing can then submit renewal work.

The certificate name and target name must be new. If ActivCERT cannot read or validate the source, match the private key, resolve a referenced object, or save the result, it removes the incomplete certificate, target, version, and generated files. Review the failed task and its events before trying again.

Adoption continues after a CERTMON restart or takeover using the same task and version. If you lose the CERTCOM session before seeing the result, inspect open and recent tasks before submitting another adoption command. After a successful adoption, another command using the same certificate or target name is rejected as a duplicate.

After a successful adoption, ActivCERT records the source target as deployed and verified at the imported version. Adoption reads the existing installation but does not rewrite it. Use INFO CERTIFICATE <certificate-name>, LINKS, INFO CERTIFICATE <certificate-name>, VERSION <number>, DETAIL, and STATUS TARGET <target-name>, DETAIL to review the new objects.

Optionally configure additional deployment targets

A managed certificate can be issued and renewed without a deployment target. Follow Deployment to add Guardian file or LightWave targets when ActivCERT should deploy versions automatically or on operator request.

Resume automatic processing if it was frozen

If the scheduler was frozen for staged configuration, thaw it after the related objects are ready. New datastores use a five-minute scheduler interval; change the interval only when site policy requires a different value:

THAW SCHEDULER
STATUS SCHEDULER, DETAIL