etoken-ca-server

NAME
SYNOPSIS
DESCRIPTION
FILES
SIGNALS
BUGS
SEE ALSO
AUTHORS
COPYRIGHT

NAME

etoken-ca-server − eToken-based CA daemon

SYNOPSIS

etoken-ca-server

DESCRIPTION

Daemon running as root, providing a fully-automated CA, where the private key is stored on a SafeNet® eToken. All configuration is done via sysconfig variables set in /etc/sysconfig/etoken-ca. The CA itself is based on the openssl ca tool. The daemon can also produce CRLs. Together with the client this provides a way to fully privilege separate a MyProxy server and the pincode for unlocking the eToken containing the private key for the CA.

The daemon, running as root, is monitoring the exchange directory /var/cache/etoken-ca/request for the appearance of a fixed-name symlink indicating a new certificate signing request, typically produced by etoken-ca-client running a ‘certificate_issuer_program’ from a MyProxy server. The client typically runs as the myproxy user.

As soon as the link appears, it obtains the target of the symlink and remove the symlink itself. It then parses the target file for a username key-value pair and a proxy_lifetime key-value pair. The username value can be suffixed with one or more email entries and a general info entry, e.g. /DC=org/O=Example/CN=John Doe email=jdoe@example.org info:key=value. The proxy lifetime value, in seconds, is used (when smaller than the maximum) for the lifetime of the issued certificate. It uses the file as PEM-encoded CSR for producing a new certificate. The email addresses are added as subjectAltName extension to the produced certificate. The subjectDN of the certificate is produced using the DN_FORMAT sysconfig variable with username (email and info bits stripped) as argument. The signing of the certificate, via openssl commandline tools, runs under the causer account.

Upon success a symlink to the newly created certificate is created in the same exchange directory /var/cache/etoken-ca/request, which will be picked up by the etoken-ca-client.

When starting, the daemon will prompt on virtual terminal 8 for the eToken pincode. This is stored in memory only, and used for signing certificates and CRLs. The daemon monitors whether the token is removed. Upon removal, the daemon will not process any requests until the pin code has been re-entered. Optionally it will also run a notifier hook under a specified account.

The daemon can be triggered to revoke certificate and/or produce new CRLs by sending it a SIGUSR1 signal. Upon receiving the signal, it will look in the /var/cache/etoken-ca/revocation for new symlinks to certificates to be revoked. It will revoke those certificates and create a new (V2) CRL. When successful, it will update the symlink to the latest CRL in rthe /var/lib/myproxyca and optionally run a POST_CRL_HOOK under the POST_CRL_USER account, which can be used for example to trigger automatic backups.

When the CA certificate does not contain CA:TRUE as Basic Constraint, the daemon will automatically produce RFC3820 proxy certificates instead of end-entity certificates.

FILES

/etc/sysconfig/etoken-ca

Configuration file for etoken-ca-client, etoken-ca-server and revoke-cert.

/var/lib/myproxyca

OpenSSL CA directory

/var/lib/myproxyca/myproxy-openssl.cnf

OpenSSL CA configuration file

/var/cache/etoken-ca/request

Directory for exchanging request and certificate between client and server.

/var/cache/etoken-ca/revocation

Directory for symlinks to to-be-revoked certificates.

SIGNALS

The following signals are caught by the server and handled specially
SIGTERM

Gracefully shut-down the server.

SIGHUP

Reopen the logfile.

SIGUSR1

Revoke pending revocation requests and produce new CRL.

BUGS

Please report any errors to the Nikhef Grid Middleware Security Team <grid-mw-security-support@nikhef.nl>.

SEE ALSO

etoken-ca-client(1), etoken-ca(5), revoke-cert(8), myproxy-server.config(5), ca(1ssl)

AUTHORS

Written by Mischa Sallé

COPYRIGHT

Copyright © 2016- FOM-Nikhef