SCP Publisher

ENTERPRISE This is an EJBCA Enterprise feature.

    Description

    For extremely secure environments, where even the Peer Publisher (which only requires an outgoing connection through a firewall) cannot function, we provide the SCP Publisher. It publishes certificates and CRLs to a remote location over SSH, which means that they can be published from a CA server which truly has all incoming traffic cut. These certificates and CRLs can later be retrieved by a VA instance and be used for OCSP responses using a Certificate and CRL Reader Service.

    Unlike the Peer Publisher, 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 Service. Another aspect to take into consideration is that the CA cannot automatically query the VA in case of a broken connection.

    images/download/attachments/143725429/Screenshot_2018-11-06_at_14.44.07.png

    Publisher Details

    Certificates and CRLs copied to the remote host are named after their SHA1 fingerprint. Only certificates with the status CertificateConstants.CERT_REVOKED or CertificateConstants.CERT_ACTIVE are published.

    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 a using a Certificate and CRL Reader Service.

    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.

    Configuration

    Configuring the SCP Publisher is as easy as using the scp command. The following parameters need to be set:

    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.

    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 DetlaCRL are used at the same time, and it also requires a dedicated Publisher for each CA.

    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).

    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 password.encryption.key in cesecore.properties in order to prohibit it from being read in cleartext from a database dump.

    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 since they typically only contain an EdDSA or ECDSA key fingerprint. To create a working known hosts-file, use the following command:

    ssh-keyscan -H -t rsa,ecdsa my.server >> known_hosts

    Make sure to change the password.encryption.key in cesecore.properties from the default value.