Prepare for External Log Shipping over TLS (Optional)

Keyfactor Command offers the option to copy audit logs in real time to a separate server for collection The certificate search function allows you to query the Keyfactor Command database for certificates from any available source based on any criteria of the certificates and save the results as a collection that will be availble in other places in the Management Portal (e.g. expiration alerts and certain reports). and analysis with a centralized logging solution (e.g. rsyslog Rsyslog is an open-source software utility used on UNIX and Unix-like computer systems for forwarding log messages in an IP network., Splunk, Elastic Stack). This can be done either over standard UDP/TCP connections, or you can opt to secure the connection to the backend log collection solution using TLS TLS (Transport Layer Security) and its predecessor SSL (Secure Sockets Layer) are protocols for establishing authenticated and encrypted links between networked computers.. This requires a backend solution that supports receiving logs over TLS and, typically, a client certificate on the Keyfactor Command server and a server certificate on the backend server.

The following instructions cover using rsyslog on the backend and will differ if you are using an alternative log collection solution.

Acquire the client certificate(s) using the Fully Qualified Domain Name (FQDN) of the server or alias used for the Keyfactor Command server(s) (see Hostname Identification and Resolution). For example:

keyfactor.keyexample.com

The certificate must be installed on the Keyfactor Command server(s) prior to installation of the Keyfactor Command software.

To acquire a client certificate for use in log shipping using a Microsoft CA A certificate authority (CA) is an entity that issues digital certificates. Within Keyfactor Command, a CA may be a Microsoft CA or a Keyfactor gateway to a cloud-based or remote CA., first create or identify a template A certificate template defines the policies and rules that a CA uses when a request for a certificate is received. that has an extended key usage (EKU) of Client Authentication and make it available for enrollment Certificate enrollment refers to the process by which a user requests a digital certificate. The user must submit the request to a certificate authority (CA). on a CA to which the Keyfactor Command server has access with enrollment permissions for the Keyfactor Command server. If desired, you can use a template that has both the Client Authentication and Server Authentication EKUs and use it for certificates on both sides of the communication. Start by copying a computer template if you want to enroll for the certificate using the Microsoft MMC as described below and without needing to set the private key Private keys are used in cryptography (symmetric and asymmetric) to encrypt or sign content. In asymmetric cryptography, they are used together in a key pair with a public key. The private or secret key is retained by the key's creator, making it highly secure. of the certificate as exportable.

To enroll for a client certificate using the MMC:

1. On the Keyfactor Command server, do one of following:
   • Using the GUI:
     1. Open an empty instance of the Microsoft Management Console (MMC).
     2. Choose File->Add/Remove Snap-in….
     3. In the Available snap-ins column, highlight Certificates and click Add.
     4. In the Certificates snap-in popup, choose the radio button for Computer account, click Next, accept the default of Local computer, and click Finish.
     5. Click OK to close the Add or Remove Snap-ins dialog.
   • Using the command line:
     1. Open a command prompt using the "Run as administrator" option.
     2. Within the command prompt type the following to open the certificates MMC:
        certlm.msc
2. Drill down to the Personal folder under Certificates for the Local Computer, right-click, and choose All Tasks->Request New Certificate….
3. Follow the certificate enrollment wizard, selecting the template you created or identified for use for this purpose, and providing any required information, being sure to set the CN A common name (CN) is the component of a distinguished name (DN) that represents the primary name of the object. The value varies depending on the type of object. For a user object, this would be the user's name (e.g. CN=John Smith). For SSL certificates, the CN is typically the fully qualified domain name (FQDN) of the host where the SSL certificate will reside (e.g. servername.keyexample.com or www.keyexample.com). to the FQDN of the Keyfactor Command server.

To acquire a server certificate for use in log shipping using a Microsoft CA, first create or identify a template that has an extended key usage (EKU) of Server Authentication and make it available for enrollment on a CA to which the server from which you are requesting the certificate has access with enrollment permissions for the server from which you are requesting the certificate.

To enroll for a server certificate using the MMC:

1. On a Windows server with appropriate enrollment access, do one of following:
   • Using the GUI:
     1. Open an empty instance of the Microsoft Management Console (MMC).
     2. Choose File->Add/Remove Snap-in….
     3. In the Available snap-ins column, highlight Certificates and click Add.
     4. In the Certificates snap-in popup, choose the radio button for Computer account, click Next, accept the default of Local computer, and click Finish.
     5. Click OK to close the Add or Remove Snap-ins dialog.
   • Using the command line:
     1. Open a command prompt using the "Run as administrator" option.
     2. Within the command prompt type the following to open the certificates MMC:
        certlm.msc
2. Drill down to Certificates in the Personal folder under Certificates for the Local Computer and locate your newly created certificate. Right-click on the certificate and choose All Tasks->Export….
3. Follow the certificate export wizard, being sure to answer Yes, export the private key and choosing the option to Include all certificates in the certificate path if possible. Set a password to secure the exported private key.
4. In the MMC, drill down to the Personal folder under Certificates for the Local Computer, right-click, and choose All Tasks->Request New Certificate….
5. Securely copy the resulting PFX file to your rsyslog server and place it in a temporary working directory.
6. Use openssl to break the PFX file apart into separate certificate and key files and remove the encryption on the key file (rsyslog does not provide a method for providing the password necessary to use the encrypted file) as follows:
   1. Execute the following command to pull the key out of the PFX file (provide the input password for the PFX when prompted and the output password for the PEM A PEM format certificate file is a base64-encoded certificate. Since it's presented in ASCII, you can open it in any text editor. PEM certificates always begin and end with entries like ---- BEGIN CERTIFICATE---- and ----END CERTIFICATE----. PEM certificates can contain a single certificate or a full certifiate chain and may contain a private key. Usually, extensions of .cer and .crt are certificate files with no private key, .key is a separate private key file, and .pem is both a certificate and private key. key file when prompted):
      openssl pkcs12 -in mycertfile.pfx -nocerts -out mykey.pem
   2. Execute the following command to pull the certificate out of the PFX file (provide the input password for the PFX when prompted):
      openssl pkcs12 -in mycertfile.pfx -clcerts -nokeys -out mycert.pem
   3. Execute the following command to pull the chain certificate(s) out of the PFX file (provide the input password for the PFX when prompted):
      openssl pkcs12 -in mycertfile.pfx -cacerts -nokeys -chain -out cacerts.pem
   4. Execute the following command to remove the encryption from the key so that a password will not be required when accessing the key file (provide the PEM key password you set in the first step):
      openssl rsa -in mykey.pem -out mynewkey.key
7. Identify a secure location on the rsyslog server to store the certificates and key file (e.g. /etc/tls/certs and /etc/tls/private) and copy the certificates and key to these locations, setting appropriately secure permissions on the files. The key needs to be readable by the rsyslog daemon.

Configuration of rsyslog for TLS support may vary depending on your needs. In addition to the standard rsyslog package for your Linux server, you will need GNU TLS packages to support TLS communication. For example, for Ubuntu the required packages are:

The following is an example rsyslog.conf file configured for TLS support:

# /etc/rsyslog.conf configuration file for rsyslog
#
# For more information install rsyslog-doc and see
# /usr/share/doc/rsyslog-doc/html/configuration/index.html
#
# Default logging rules can be found in /etc/rsyslog.d/50-default.conf
#################
#### MODULES ####
#################

module(load="imuxsock") # provides support for local system logging
#module(load="immark")  # provides --MARK-- message capability

# provides UDP syslog reception
#module(load="imudp")
#input(type="imudp" port="514")

# provides TCP syslog reception
#module(load="imtcp")
#input(type="imtcp" port="514")

# provides kernel logging support and enable non-kernel klog messages
module(load="imklog" permitnonkernelfacility="on")

###########################
#### GLOBAL DIRECTIVES ####
###########################

#
# Use traditional timestamp format.
# To enable high precision timestamps, comment out the following line.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# Filter duplicated messages - It can be helpful to set this 'off' during initial Keyfactor Command testing
$RepeatedMsgReduction off

#
# Set the default permissions for all log files.
#
$FileOwner syslog
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
$PrivDropToUser syslog
$PrivDropToGroup syslog

#
# Where to place spool and state files
#
$WorkDirectory /var/spool/rsyslog

#
# Include all config files in /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf

#
# Configuration for TLS
#
$DefaultNetstreamDriver gtls

$DefaultNetstreamDriverCAFile /etc/tls/certs/cacerts.pem
$DefaultNetstreamDriverCertFile /etc/tls/certs/mycert.pem
$DefaultNetstreamDriverKeyFile /etc/tls/private/mynewkey.key

$ModLoad imtcp

$InputTCPServerKeepAlive on
$InputTCPServerStreamDriverAuthMode anon
$InputTCPServerStreamDriverMode 1 # run driver in TLS-only mode

$ActionSendStreamDriverAuthMode x509/name
$ActionSendStreamDriverMode 1 # run driver in TLS-only mode

$InputTCPServerRun 10514

A filter similar to the following can be used to redirect all Keyfactor Command related traffic to a particular file: