SCP Publisher
The SCP Publisher enables secure publication of certificates and CRLs to remote servers over SCP or SFTP.
For more information on different publishers and their purposes, see Publishers Overview.
Introduction
For security-aware networks where you want to minimize traffic to your Certificate Authority (CA), EJBCA supports using specific instances as CAs and others as Validation Authorities (VAs). A VA is typically deployed in a different network zone than a CA, where the latter has more protection. Data synchronization between the CAs and the VAs is necessary to ensure that the VAs are distributing information about certificate status, OCSP, Certificate Revocation Lists (CRLs), and so on.
By configuring EJBCA's SCP Publisher, certificate status and CRLs can be published to a remote host using SCP/SFTP, thereby avoiding sending incoming traffic to the CA. By combining the SCP Publisher on the CA with the EJBCA Certificate and CRL Reader Service on the VA, you can securely update the certificate and CRL data in your VA regularly.
SCP publishing will not be instantaneous. Although the CRL or certificate is written to the remote host directly after issuance, there will be a delay before the changes are picked up by the VA. The delay incurred depends on the periodic interval configured for the Certificate and CRL Reader Service. Another aspect to take into consideration is that the CA cannot automatically query the VA in case of a broken connection.
With EJBCA Enterprise Edition, you can integrate your CA with your VAs and RAs using the peer publisher, see Validation Authority Peer Publisher.
Publisher Details
Certificates and CRLs copied to the remote host are named after their SHA1 fingerprint. Only certificates with the following statuses are published:
CertificateConstants.CERT_REVOKEDCertificateConstants.CERT_ACTIVE
The data written to the remote host is either a DER-encoded CRL or a serialized org.ejbca.scp.publisher.ScpContainer object, in order to retain revocation details and other pertinent information. If a signing CA is used, the data is wrapped in a CMS envelope. The data can later be retrieved by using the Certificate and CRL Reader Service.
Configure SCP Publisher
To configure an SCP Publisher, follow these steps:
Go to CA Functions > Publishers.
Select the SCP Publisher from the List of Publishers and click Edit Publisher.
On the Edit Publisher page, select the Publisher Type ScpPublisher (Custom Publisher).
Specify the publisher settings (described in SCP Publisher Settings below).
Complete the remaining publisher settings (described in Publishers Overview).
Click Save and Test Connection to store the information and validate the configuration.
Once the publisher is created, it needs to be selected in the Certificate Profile Publishers list to be activated. For details, see Publishers Management.
Save and Test Connection
To verify the configuration, click Save and Test Connection to attempt to establish a connection to the destination server. Note that this will not write any data to the server and will hence not verify any server-side access rights.
SCP Publisher Settings
Configuring the SCP Publisher is similar to using the scp command. The following parameters are available.
Parameter | Description |
|---|---|
CA to Sign Published Certificate | If the published certificate/CRL should be individually signed by CA before being copied to the destination. |
Publish Without Identifying Information | If identifying information (such as the contents of the Subject DN, SAN, etc) should be redacted, in compliance with GDPR and other privacy regulations. |
Username for SSH Connection | The username used to establish the SSH connection. |
Port for SSH Connection | The port for establishing the SSH connection. By default, port 22 is used. |
Destination URL for Certificates/CRLs | URL for the end destination of the certificate/CRL files, including directory, in the format: domain.name:/path/to/folder/ If a fixed CRL file name is added to the destination location, it will publish a single file of the CA with the specified name. Existing CRLs will be overwritten. Example: download.widgetcorp.com:tmp/SubCA.crl. Note that this is not suitable if both regular and DeltaCRL are used at the same time, and it also requires a dedicated Publisher for each CA. |
CRL file name pattern | By default, EJBCA uses the fingerprint of the CRL as its filename. While this works well with the CertificateCrlReader, it can cause confusion when integrating with external systems that expect predictable filenames. To address this, you can specify a constant or template-based filename pattern, see CRL File Name Templates. It is recommended to schedule the CertificateCrlReader to run at half the validity interval of the CRL or delta CRL when the CRL filename remains constant for a given CA. For example, if a CRL or delta CRL is generated every hour, configure the CertificateCrlReader to run every 30 minutes to ensure timely synchronization. Introduced in EJBCA 9.4. |
Use SFTP | Recommended for better compatibility and security. Uses a key pair from an EJBCA crypto token for authentication. Introduced in EJBCA 9.4. |
Cryptotoken and Keypair for authentication | Specifies the crypto token and corresponding key pair for authentication while using SFTP. Supports RSA, ED25519, and EC keys (with curve P-256, P-384, P-521). Introduced in EJBCA 9.4. Only RSA, ED25519 and EC keys with curve P-256,P-384 and P-521 can be used. The key pair needs must be added as an authorized SSH public key on the remote host. When Save and Test Connection is clicked, the corresponding public key is displayed under SSH Public Key used for authentication. |
SSH Known hosts | Add known host entries here (one per line). When the host is unknown, EJBCA displays the entry as an error during connection testing. Both plain and hashed hostnames are supported. Introduced in EJBCA 9.4. If you click Save and Test Connection and the host is unknown, EJBCA displays the entry as an error during connection testing. Both plain and hashed host names are supported. Example:
CODE
|
Export Format | Choose the export format: Existing publishers will continue to use the Java format and are not automatically updated. YAML is the new default format for new publishers. Introduced in EJBCA 9.4. If you use a CA to sign the message containing a published certificate and want to validate the signature, see Signature Validation for Published Certificates as YAML. |
Path to Private Key File | Path to a local private key used to establish the connection. A corresponding public key should exist in the same directory with the same name and the .pub suffix. The private key file must be in PKCS#8 PEM or OpenSSH PEM format. If you generate the key using the ssh-keygen command, you must use the "-f PEM" option to generate the private key in OpenSSH PEM format (otherwise it will use RFC4716 format which is currently not supported). Deprecated since EJBCA 9.4. Used only when SCP (not SFTP) is configured. |
Password to Private Key File | Password to the private key. The field may be left blank if the private key is not password protected. The password is encrypted in the database using the passphrase defined by Always change the Deprecated since EJBCA 9.4. Used only when SCP (not SFTP) is configured. |
Path to Known Hosts File | Path to the file of known hosts. EJBCA enforces host key checking for security. The known hosts file must contain the fingerprint of the server's public RSA key. Be wary of copying an existing known hosts file since they typically only contain an EdDSA or ECDSA key fingerprint. To create a working known hosts file, use the following command:
CODE
Deprecated since EJBCA 9.4. Used only when SCP (not SFTP) is configured. |
CRL File Name Templates
By default, EJBCA uses the fingerprint of the CRL as its filename. While this works well with the CertificateCrlReader, it can cause confusion when integrating with external systems that expect predictable filenames. To address this, you can specify a constant or template-based filename pattern.
Use a constant filename (for example, IssuerCA.crl) if the publisher is configured for a single CA.
If the publisher is used for multiple CAs, define a template such as ${CA_NAME}.crl to generate unique filenames dynamically (for example, IssuerCA.crl, ManagementCA.crl).
You can also combine multiple templates to create more descriptive filenames.
For example: ${CA_NAME}${DELTA}${PARTITION}.crl
It is recommended to schedule the CertificateCrlReader to run at half the validity interval of the CRL or delta CRL when the CRL filename remains constant for a given CA. For example, if a CRL or delta CRL is generated every hour, configure the CertificateCrlReader to run every 30 minutes to ensure timely synchronization.
Allowed template options:
Examples are shown for a CA saved with name IssuerCA and subject DN CN=MyIssuer,OU=MyOrg.
Template | Meaning | Example |
|---|---|---|
| Use the name of the CA in EJBCA in template |
|
| Use the Common Name or CN of the CA’s subjectDN. Recommended when the CA uses special or non-latin characters in the name. |
|
| Use the CA’s subjectDN. Useful when the same common name is used across multiple CAs. |
|
| Use the CRL number. |
|
| Puts |
|
| Puts |
|
Recommended patterns:
Fixed CRL name per CA:
${CA_NAME}${DELTA}${PARTITION}.crlPredictable historical naming (the CRL Number is incremented on each CRL generation):
${CA_NAME}_${CRL_NUMBER}${DELTA}${PARTITION}.crl
Signature Validation for Published Certificates as YAML
SCP Publisher can publish certificates as YAML, allowing the certificates to be consumed by external systems.
Certificates can be published with or without a signature of a CA, depending on whether CA to Sign Published Certificate is enabled.
Unsigned example:
certificate: |
-----BEGIN CERTIFICATE-----
MIIDMTCCAhmgAwIBAgIUVgJjVAw1jZz9W8Wx2aRJ7IjcO+8wDQYJKoZIhvcNAQEL
..... truncated ....
sILfq2a8pnTv+l2lOvjw8kcGAy150T6MAqO+QTsgP2r8mj1ObFDOGp9NDevont9x
lUUqAeU=
-----END CERTIFICATE-----
certificateProfile: 1669368783
certificateProfileName: DeviceCertProfile
certificateStatus: 20
certificateType: 1
issuer: CN=Ca001
latestVersion: 0.0
revocationDate: -1
revocationReason: -1
serialNumber: 491026460497502125894261848387952441916491840495
subjectDn: CN=some-device
updateTime: 1749638702661
username: device1
Signed example:
data:
certificate: |
-----BEGIN CERTIFICATE-----
MIIDMTCCAhmgAwIBAgIUVgJjVAw1jZz9W8Wx2aRJ7IjcO+8wDQYJKoZIhvcNAQEL
..... truncated ....
sILfq2a8pnTv+l2lOvjw8kcGAy150T6MAqO+QTsgP2r8mj1ObFDOGp9NDevont9x
lUUqAeU=
-----END CERTIFICATE-----
certificateProfile: 1669368783
certificateProfileName: DeviceCertProfile
certificateStatus: 20
certificateType: 1
issuer: CN=Ca001
latestVersion: 0.0
revocationDate: -1
revocationReason: -1
serialNumber: 491026460497502125894261848387952441916491840495
subjectDn: CN=some-device
updateTime: 1749638702661
username: device1
signature: |-
MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcB
..... truncated ....
QHknFRwYIsqjCw6V0LHjAAAAAAAA
The signature contains the signature along with the contents of the data section (using Unix newline\n) following the https://datatracker.ietf.org/doc/html/rfc2315#section-9.1 format as implemented byhttps://downloads.bouncycastle.org/java/docs/bcpkix-jdk18on-javadoc/org/bouncycastle/cms/CMSSignedData.html. It can be verified using BouncyCastle’s CMSSignedData implementation or any compliant alternative.