Miscellaneous

*** No authentication ***

AUTHTYPE = NOAUTH

Sets the server to not require any authentication.

*** Client certificate authentication ***

AUTHTYPE = CLIENTCERT

(default) requires a certificate of all the clients. The certificates must be in the signers access control list and be trusted by the Java distribution, i.e imported in JAVA_HOME/jre/lib/security/cacerts. Authorized clients is configured manually using the CLI interface.

*** Username/password-based authentication ***

AUTHTYPE = org.signserver.server.UsernamePasswordAuthorizer

USER.[NAME] = [PASSWORD]
USER.[NAME] = [HASHED_PASSWORD]:[HASH_ALGORITHM]
USER.[NAME] = [HASHED_PASSWORD]:[HASH_ALGORITHM]:[SALT]

This authorizer requires a valid username and password. User accounts are configured by setting properties of the form shown above, where [NAME] is the username and [PASSWORD] is the clear-text password. In the second form [HASHED_PASSWORD] should be replaced with the output of the digest algorithm specified in [HASH_ALGORITHM]. The third form uses a hash value that is appended to the password before hashing it.

If a valid username and password is not supplied the worker throws an AuthorizationRequiredException which in case of the HTTP interfaces causes a HTTP Basic Authentication (RFC 2617).

*** Username-based authentication ***

AUTHTYPE = org.signserver.server.UsernameAuthorizer

Form 1: ACCEPT_ALL_USERNAMES = false (default) and usernames are specified:
ACCEPT_ALL_USERNAMES = false
ACCEPT_USERNAMES = user1;user2;user3

Form 2, ACCEPT_ALL_USERNAMES = true and no usernames are specified:
ACCEPT_ALL_USERNAMES = true

An Authorizer that can be used for instance if SignServer sits behind an Apache front-end which uses HTTP basic authentication. With this Authorizer the username is logged but the password is not checked as it is assumed to be checked by the front-end.

The Authorizer can be configured to either accept all usernames or only accept those usernames listed in one of its properties.

*** Remote address authentication ***

AUTHTYPE = org.signserver.server.RemoteAddressAuthorizer

ALLOW_FROM = Comma separated list of IP addresses to allow requests from. By default all other addresses are denied access.

If a worker is invoked directly using an EJB call and no REMOTE_IP is specified in the RequestContext the IP-address is set to the String "null". In that case, to allow requests using EJB calls, null can be added to the list of allowed addresses.

*** Custom ***

This authorization functionality doesn't work for all use cases. Then it's possible to create a customized authorizer and specify it's class path as value in the AUTHTYPE property. The Processable will then automatically instantiate and use it. How to develop such a plug-in is explained in the developers section.

*** Overview ***

The CertificateExpireTimedService is a timed service specific for the MailSigner. It checks all available mail processors if they have a certificate about to expire. In that case a notification about this is sent to the administrators. By default is this done 30 days before expiration. If the Mail Processor isn't updated a reminder message is sent.

The CertificateExpireTimedService have the class path: org.signserver.mailsigner.module.common. CertificateExpireTimedService and is compiled into a the dist-server/mailsigner-module-common.jar that can be included in MAR files that needs the service.

*** Available Properties ***

EXPIRETIMEDAYS = Number of remaining days of the certificate before a notification is sent.(Optional, default 30 days).

REMINDERTIMEDAYS = Number of remaining days of the certificate before a reminder notification is sent.(Optional, default 10 days).

ADMINEMAIL = The email address of were the notifications is sent. (Optional, default is the configured postmaster address.)

FROMEMAIL = The from email used in the notifications is sent. (Optional, default is certexpire@<postmaster-domain>)

MESSAGESUBJECT = The subject used in the first notification message. (Optional, default is "WARNING: Mail Processor with id : ${WORKERID} is about to expire.")

REMINDERSUBJECT = The subject used in the reminder notification message. (Optional, default is "REMINDER: Mail Processor with id : ${WORKERID} is about to expire.")

EXPIREMESSAGE = The message body in the notifications is sent. (Optional, default is "A mail processor at host ${HOSTNAME} have a certificate about to expire.${NL}${NL}The Mail Processor have id ${WORKERID} and a certificate with DN '${cert.CERTSUBJECTDN}' and will expire the ${cert.EXPIREDATE}. ${NL}")

REMINDERMESSAGE = The message body in the remainder notifications is sent. (Optional, default is "This is a reminder that a mail processor at host ${HOSTNAME} have a certificate about to expire.${NL}${NL}The Mail Processor have id ${WORKERID} and a certificate with DN '${cert.CERTSUBJECTDN}' and will expire the ${cert.EXPIREDATE}. ${NL}")

*** Available Substitution Variables ***

The following substitution variables can be used in notification subject and message bodys.

${NL} = New line
${DATE} = The current date
${HOSTNAME} = Name of the host running the application.
${WORKERID} = Id of the worker.
${WORKERNAME} = Name of the worker.
${cert.CERTSERIAL} = The serial number of the certificate about to expire.
${cert.EXPIREDATE} = The certificates expiration date.
${cert.CERTSUBJECTDN} = The certificate subject DN.
${cert.CERTISSUERDN} = The certificate issuer DN.

*** Overview ***

The SignerStatusReportTimedService is a timed service that outputs status for a set of signers to a file. The information includes each signers current status ACTIVE/OFFLINE and if available also the numbers of signings that has been performed with the key currently associated with the signer. If the signer has a configured limit of number of signers, this value is also included.

Sample content of a produced output file:

workerName=Sod1, status=OFFLINE, signings=10000, signLimit=10000,
workerName=Sod2, status=ACTIVE, signings=33524, signLimit=100000,
workerName=Sod3, status=OFFLINE, signings=10000, signLimit=10000,
workerName=Sod4, status=OFFLINE, signings=10000, signLimit=10000,
workerName=Sod5, status=OFFLINE, signings=10000, signLimit=10000,
workerName=Sod6, status=ACTIVE, validityNotBefore=2010-04-04 01:37:21 CEST, validityNotAfter=2018-04-04 01:37:21 CEST, signings=4676,
workerName=Sod7, status=OFFLINE,
                        

*** Available Properties ***

WORKERS = Comma separated list of worker names (signers) that should be monitored.

OUTPUTFILE = File that the information will be written to. If the file exists the content will be overwritten. The application server needs to have write access to this file when the service is executed.

*** SignServer Node ***

The server part of the SignServer package contains everything (except Java) that is needed to set-up a node in a cluster. It contains a preconfigured version of JBoss that is ready to use.

The steps performed during the installation process are:

Unix:

• By default is everything unpacked in /opt/signserver-<version> .
• If a /etc/signserver/signserver.conf file exists, it's read and used during installation.
• The user and group 'signserver' is created
• JBoss init.d script is configured to run at runlevel 3,4,5
• Directory /etc/signserver/ is created to contain all configuration files
• Database configuration file /etc/signserver/database-conf.xml is populated.
• Log configuration file /etc/signserver/log-conf.xml is populated and configured to log to the directory /var/log/signserver
• If no HTTP SSL certificate is specified in the configuration file will dummy key stores be generated to /etc/signserver.
• Tomcat is configured for HTTPS and it's configuration file is placed in /etc/signserver/webserver-conf.xml
• Finally is Jboss started and ready to be used.

Windows:

• By default is everything unpacked in C:\Program\SignServer\SignServer-<version> .
• If a c:\WINDOWS\signserver.conf file exists it's read and used during installation.
• JBoss is configured to be run as a service that is started automatically.
• Database configuration file <INSTALLDIR>\database-conf.xml is populated.
• Log configuration file <INSTALLDIR>\log-conf.xml is populated and configured to log to the default directory <INSTALLDIR>\jboss\server\default\log
• If no HTTP SSL certificate is specified will dummy key stores be generated to <INSTALLDIR>
• Tomcat is configured for HTTPS and it's configuration file is placed in <INSTALLDIR>\webserver-conf.xml
• Finally is Jboss started and ready to be used.

The supported properties in the configuration file /etc/signserver/signserver.conf (or %SYSTEMROOT%\signerserver.conf for windows) are:

*** SignServer Management ***

This package installs the CLI interface on the management station (which can be the same as a node). The following steps are performed during installation:

Unix:

• By default is everything unpacked in /opt/signserver-<version> .
• If a /etc/signserver/signserver.conf file exists it's read and used during installation.
• The user and group 'signserver' is created
• A link from /opt/signserver-<version>/bin/signserver.sh is done to /usr/local/bin.

Windows:

• Everything is unpacked in C:\Program\SignServer\SignServer-<version> by default.
• If a c:\WINDOWS\signserver.conf file exists it's read and used during installation.

The signserver.conf supports the following settings:

*** MailSigner Server ***

The MailSigner package works much in the same way as the SignServer package with the difference that James SMTP server is included instead of Jboss.

The steps performed during the installation process are:

Unix:

• By default is everything is unpacked in /opt/mailsigner-<version> .
• If a /etc/mailsigner/mailsigner.conf file exists it's read and used during installation.
• The user and group 'mailsigner' is created
• James init.d script is configured to run at runlevel 3,4,5
• Directory /etc/mailsigner/ is created to contain all configuration files
• James configuration file /etc/mailsigner/mailsigner_conf.xml is populated.
• Log configuration file /etc/mailsigner/log-conf.xml is populated and configured to log to the directory /var/log/mailsigner
• Finally is James started and ready to be used.

Windows:

• By default is everything is unpacked in C:\Program\MailSigner\MailSigner-<version> .
• If a c:\WINDOWS\mailsigner.conf file exists it's read and used during installation.
• James is configured to be run as a service that is started automatically.
• James configuration file <INSTALLDIR>\mailsigner_conf.xml is populated.
• Log configuration file <INSTALLDIR>\log-conf.xml is populated and configured to log to the default directory <INSTALLDIR>\james\logs
• Finally is James started and ready to be used.

The supported properties in the configuration file /etc/mailsigner/mailsigner.conf (or %SYSTEMROOT%\mailsigner.conf for windows) are:

*** MailSigner Management ***

This package installs the CLI interface on the management station (which can be the same as the SMTP server). The following steps are performed during installation:

Unix:

• By default is everything is unpacked in /opt/mailsigner-<version> .
• If a /etc/mailsigner/mailsigner.conf file exists it's read and used during installation.
• The user and group 'mailsigner' is created
• A link from /opt/mailsigner-<version>/bin/mailsigner.sh is done to /usr/local/bin.

Windows:

• Everything is unpacked in C:\Program\MailSigner\MailSigner-<version> by default.
• If a c:\WINDOWS\mailsigner.conf file exists it's read and used during installation.

The mailsigner.conf supports the following settings but it is important that 'hostname.masternode' and 'hostname.allnodes' must point to the same host: