-Semicolon-separated base 64-encoded certificates of the signer's own signer certificate chain.
+Semicolon-separated base 64-encoded certificates of the signer's own signer certificate chain.
Returns the status of the given worker, stating if its crypto token is active or not, and the loaded 'active' configuration. It is possible to get a brief summary or a complete listing for one worker or all configured workers. If all workers are displayed, all the global configuration parameters will also be displayed.
+
Returns the status of the given worker, stating if its crypto token is active or not, and the loaded 'active' configuration. It is possible to get a brief summary or a complete listing for one worker or all configured workers. If all workers are displayed, all the global configuration parameters will also be displayed.
getconfig
@@ -1878,7 +1882,7 @@
Authorization Related
Authorization related commands are used to configure the client authorization rules for a worker when the Client Certificate Authorizer is used as AUTHTYPE.
authorizedclients
-
Command for adding, removing or listing a worker's client authorization rules. Replaces the legacy commands addauthorizedclient, removeauthorizedclient and listauthorizedclient.
+
Command for adding, removing or listing a worker's client authorization rules. Replaces the legacy commands addauthorizedclient, removeauthorizedclient and listauthorizedclient.
Usage: signserver authorizedclients -worker <worker name or ID> -list
Edit -> Remove worker...: Removes the selected workers from the SignServer configuration.
Edit -> Reload from database...: Reloads the global configuration or the selected workers from the database. This is only needed if the configuration was changed from an other node and the nodes uses a shared database.
Edit -> Global configuration...: Opens the Global configuration window.
-
Edit -> Administrators...: Opens the Administrators window. Allows adding webservice administrators, auditors, and archive auditors. The administrators can be added by explicitly entering the client certificate's serial number in hexadecimal (leading zeroes and letter case is not significant) and the issuer DN with space after each comma separating DN components. If DN components contains commas, these needs to be escaped with backslashes.
+
Edit -> Administrators...: Opens the Administrators window. Allows adding webservice administrators, auditors, and archive auditors. The administrators can be added by explicitly entering the client certificate's serial number in hexadecimal (leading zeroes and letter case is not significant) and the issuer DN with space after each comma separating DN components. If DN components contains commas, these needs to be escaped with backslashes.
An example using a certificate issued from EJBCA with the default (as specified by EJBCA) LDAP DN order:
C=SE, O=TestOrganization, CN=IssuingCA
This is the reversed order compared to how the issuer DN is stored in the certificate. An example using a certificate issued from EJBCA with the Use LDAP DN order option disabled:
@@ -1808,7 +1812,7 @@
Main window: Status Properties Tab
Main window: Configuration Tab
-
Lists all the selected worker's configuration properties and gives the ability to add, remove or edit properties.
+
Lists all the selected worker's configuration properties and gives the ability to add, remove or edit properties.
Add...: Adds a new property to the selected worker.
Edit: Edit the selected property.
Remove: Removes the selected property.
@@ -1833,7 +1837,7 @@
Main window: CryptoToken Tab
-
This dialog is different from the Renew key dialog as in this case the worker's next key property (NEXTCERTSIGNKEY) is not updated.
+
This dialog is different from the Renew key dialog as in this case the worker's next key property (NEXTCERTSIGNKEY) is not updated.
Test: Opens the Test key dialog for the selected entry.
@@ -1842,7 +1846,7 @@
Main window: CryptoToken Tab
-
Installing certificates this way it is only possible to store the certificates in the token and the worker's current key (DEFAULTKEY) and next key (NEXTCERTSIGNKEY) properties are not updated.
+
Installing certificates this way it is only possible to store the certificates in the token and the worker's current key (DEFAULTKEY) and next key (NEXTCERTSIGNKEY) properties are not updated.
Remove: Opens the Remove key dialog with the selected key aliases already filled in.
@@ -1886,7 +1890,7 @@
Main window: Archive
Renew key dialog
-
Generates new keys for all the listed workers. For this to work all workers should have the same password. Key algorithm, Key specification and New key alias must be specified if it is not taken from the worker's configuration.
+
Generates new keys for all the listed workers. For this to work all workers should have the same password. Key algorithm, Key specification and New key alias must be specified if it is not taken from the worker's configuration.
Test key dialog
@@ -1894,19 +1898,19 @@
Test key dialog
Generate CSR dialog
-
Generates certificate signing requests (CSR:s) in PKCS#10 format for all listed signers. In the key dropdown menu either the current key (DEFAULTKEY) or the next key can be selected. It is also possible to manually enter a value in the field to generate a CSR for a specific key alias in the crypto token. Signature algorithm, subject distinguished name (DN) and Filename must be specified if not already taken from the worker's configuration. The format of the request could either be a Standard CSR file or a CSR wrapped in PKCS#7/CMS signed object created by a RequestSigner. The with the last option is that at the CA the signature of the request can be verified.
+
Generates certificate signing requests (CSR:s) in PKCS#10 format for all listed signers. In the key dropdown menu either the current key (DEFAULTKEY) or the next key can be selected. It is also possible to manually enter a value in the field to generate a CSR for a specific key alias in the crypto token. Signature algorithm, subject distinguished name (DN) and Filename must be specified if not already taken from the worker's configuration. The format of the request could either be a Standard CSR file or a CSR wrapped in PKCS#7/CMS signed object created by a RequestSigner. The with the last option is that at the CA the signature of the request can be verified.
Install certificates
Installs signer certificate and certificate chains for the listed workers and if next key is chosen that key becomes the new default key.
At least one of Signer certificate and Signer certificate chain columns needs to be filled in. If a file is chosen for Signer certificate then the first certificate from that file will be used as signer certificate. It will also be added to the beginning of the certificate chain (if it is not already there). If a file is chosen for Signer certificate chain then all of the certificates from that file will be included in the certificate chain. The first certificate will be used as signer certificate (if a Signer certificate was not chosen).
-
If the Install in token check box is selected, the certificate chain will be imported to the worker's crypto token (if the crypto token supports this operation). When this is selected, the key alias to import the chain to in the token can be manually entered in the key column. This is currently only supported for keystore and PKCS11 crypto tokens.
+
If the Install in token check box is selected, the certificate chain will be imported to the worker's crypto token (if the crypto token supports this operation). When this is selected, the key alias to import the chain to in the token can be manually entered in the key column. This is currently only supported for keystore and PKCS11 crypto tokens.
Signer certificate: Browse for the signer certificate file in PEM format.
Certificate chain: Browse for the signer certificate chain file (or CA certificate(s)) in PEM format.
Renew signer dialog
-
Requests a Renewal worker to renew all the chosen and selected workers. The Renewal worker will generate a new key if there isn't already a next key available and then contact EJBCA using its web service interface to request a new certificate. After receiving the new certificate it is installed and the next key becomes the current default key. Notice how the Not valid after date and possibly also the Signings column changes and the Renewal checkbox gets unchecked after a successful renewal.
+
Requests a Renewal worker to renew all the chosen and selected workers. The Renewal worker will generate a new key if there isn't already a next key available and then contact EJBCA using its web service interface to request a new certificate. After receiving the new certificate it is installed and the next key becomes the current default key. Notice how the Not valid after date and possibly also the Signings column changes and the Renewal checkbox gets unchecked after a successful renewal.
A signer can be configured using the EXPLICTECC parameter (see Other Properties) to encode the EC parameters explicitly in the request. This goes for the supported named curves but a named curve is still needed when generating the key-pair.
But certificates with explicit EC parameters can no be read from the token.
-
+
If the token contains certificates with explicit parameters the token can not be used by this crypto token until those certificates has been removed!
Instead store the certificates in the worker configuration and certificates with explicit EC parameters can be used that way.
The operators available depend on the chosen column. Possible values:
-
Equals: The column's value should be equal to the value provided.
-
Greater or equals: The column's value should be equal to the value provided or be greater.
-
Greater than: The column's value should be greater than the provided value.
-
Lesser or equals: The column's value should be equal to the value provided or be lesser.
-
Lesser than: The column's value should be lesser than the provided value.
-
Like: The column's value should be 'like' to the value provided. The % sign can be used as a wild card in the beginning and/or end to match on values containing the provided value.
-
Not Equals: The column's value should be any other value than the provided.
-
Is not null: The column's value should not be null.
-
Is null: The column's value should be null.
+
Equals: The column's value should be equal to the value provided.
+
Greater or equals: The column's value should be equal to the value provided or be greater.
+
Greater than: The column's value should be greater than the provided value.
+
Lesser or equals: The column's value should be equal to the value provided or be lesser.
+
Lesser than: The column's value should be lesser than the provided value.
+
Like: The column's value should be 'like' to the value provided. The % sign can be used as a wild card in the beginning and/or end to match on values containing the provided value.
+
Not Equals: The column's value should be any other value than the provided.
+
Is not null: The column's value should not be null.
The operators available depend on the chosen column. Possible values:
-
Equals: The column's value should be equal to the value provided.
-
Greater or equals: The column's value should be equal to the value provided or be greater.
-
Greater than: The column's value should be greater than the provided value.
-
Lesser or equals: The column's value should be equal to the value provided or be lesser.
-
Lesser than: The column's value should be lesser than the provided value.
-
Like: The column's value should be 'like' to the value provided. The % sign can be used as a wild card in the beginning and/or end to match on values containing the provided value.
-
Not Equals: The column's value should be any other value than the provided.
-
Is not null: The column's value should not be null.
-
Is null: The column's value should be null.
+
Equals: The column's value should be equal to the value provided.
+
Greater or equals: The column's value should be equal to the value provided or be greater.
+
Greater than: The column's value should be greater than the provided value.
+
Lesser or equals: The column's value should be equal to the value provided or be lesser.
+
Lesser than: The column's value should be lesser than the provided value.
+
Like: The column's value should be 'like' to the value provided. The % sign can be used as a wild card in the beginning and/or end to match on values containing the provided value.
+
Not Equals: The column's value should be any other value than the provided.
+
Is not null: The column's value should not be null.
Default value. Requires a certificate of all the clients. The certificates must be in the application server's truststore. Authorized clients is configured manually using the CLI interface.
+
Default value. Requires a certificate of all the clients. The certificates must be in the application server's truststore. Authorized clients is configured manually using the CLI interface.
The key alias of the private key to be used for testing that this crypto token is working.
-
+
If this key does not exist, the crypto token/worker will show as OFFLINE even if it has been activated. This is typically the case when the crypto token has been set up for the first time and the key has not yet been generated. To resolve, generate a key with the key alias name.
A property with this name is typically also accepted by the worker using this crypto token and will then be the key to use for actual signing.
-
+
@@ -1793,10 +1797,10 @@
Available Properties
KEY_VAULT_NAME
-
The name of the key vault. If the name contains at least one dot, it's assumed to be the full host name of the vault (allowing for alternative endpoints), otherwise it's assumed to be the first part of a host name in the default namespace (<KEY_VAULT_NAME>.vault.azure.net).
+
The name of the key vault. If the name contains at least one dot, it's assumed to be the full host name of the vault (allowing for alternative endpoints), otherwise it's assumed to be the first part of a host name in the default namespace (<KEY_VAULT_NAME>.vault.azure.net).
-
+
@@ -1808,7 +1812,7 @@
Available Properties
Client ID, this is the “AD user” that is authorized to connect to and use the key vault.
-
+
@@ -1820,7 +1824,7 @@
Available Properties
The type of key vault. Valid values: “standard” or ”premium”.
-
+
@@ -1833,7 +1837,7 @@
Know Limitations
Import of certificate in token is not supported for this crypto token.
The Azure Key Vault Crypto Token does not provide any certificates and cannot be used with signers that require a certificate from the token such as OpenPGP-based signers. For details on PGP signing support, refer to DSS-2127.
-If the Key Vault has soft-delete enabled, the keys will not be completely deleted by SignServer and new keys cannot be created with the same name as keys that have been soft-deleted. For more information on the Key Vault's soft-delete feature, allowing recovery of the deleted vaults and vault objects, refer to the Microsoft Azure Key Vault soft-delete overview.
+If the Key Vault has soft-delete enabled, the keys will not be completely deleted by SignServer and new keys cannot be created with the same name as keys that have been soft-deleted. For more information on the Key Vault's soft-delete feature, allowing recovery of the deleted vaults and vault objects, refer to the Microsoft Azure Key Vault soft-delete overview.
The CMS signer has the fully qualified class name: org.signserver.module.cmssigner.CMSSigner.
-
+
Overview
The CMS signer can sign arbitrary data and produces a CMS (RFC 3852) SignedData structure in binary format with or without the content encapsulated. Currently the signer certificate is always included.
-
+
Available Properties
@@ -1751,7 +1755,7 @@
Available Properties
SIGNATUREALGORITHM
-
Property specifying the algorithm used to sign the data. Default: depending on the signing key: SHA256withDSA for DSA keys, SHA256withECDSA for ECDSA keys, otherwise SHA256withRSA.
+
Property specifying the algorithm used to sign the data. Default: depending on the signing key: SHA256withDSA for DSA keys, SHA256withECDSA for ECDSA keys, Ed25519 or Ed448 or EdDSA keys, otherwise SHA256withRSA.
@@ -1801,7 +1805,7 @@
Available Properties
Property specifying if the resulting data structure should be parsed and re-encoded using DER encoding. Default: false.
-
+
This option is performed in memory and thus does not support large files.
@@ -1827,7 +1831,7 @@
Available Properties
Property specifying that the signature should be calculated directly over the content and not over signed attributes. Thus the signature would not contain any signed attributes if this property is set to true. Default: false.
-
+
Setting this to true is not allowed when CLIENTSIDEHASHING or ALLOW_CLIENTSIDEHASHING_OVERRIDE is configured.
@@ -1866,7 +1870,7 @@
Available Properties
-
+
Request parameters
The following meta data parameters can be specified in a request
@@ -1911,7 +1915,7 @@
Request parameters
-
+
Signing a pre-computed hash
For background and information on how to use this mode with CMS signatures, see Client Side Hashing.
The following lists algorithm support for the CMS Signer.
-
+
Signature Algorithms
The signer also relies on support for the algorithm in the Crypto Token used, so also review that the desired algorithm is supported by the configured crypto token.
SignServer generates the CSR and returns it to EJBCA.
EJBCA processes the request, issues the certificate, and sends it to SignServer.
SignServer installs the certificate to the worker and also adds the worker property PEERS_ISSUED=true to indicate that the certificate was issued by a peer.
-
The new certificate(s) can now be seen when looking at the worker's status. In EJBCA, the remote key binding will now show the Boundcertificate and the button will now instead be named Renew.
+
The new certificate(s) can now be seen when looking at the worker's status. In EJBCA, the remote key binding will now show the Boundcertificate and the button will now instead be named Renew.
The algorithm used for signing the CSR as well as subject DN to include etc was using the default values. To choose other values, see information on available worker properties on the Peer Systems page.
Subsequent Renewals/Rekeyings
-
The next time it is time to renew or rekey a worker's certificate, everything should already have been set-up as part of the previous steps and in EJBCA the Renew button should be available.
+
The next time it is time to renew or rekey a worker's certificate, everything should already have been set-up as part of the previous steps and in EJBCA the Renew button should be available.
In order to also generate a new key-pair (i.e. to rekey), select the key pair in EJBCA to be rekeyed.
The following describes various options for performing the hashing on the client-side instead of making all the steps in the signing on the server-side. Client-side hashing is also sometimes referred to as "hash signing" and the main advantage is that the original file does not need to be sent to the server.
Detached signatures allow the signature to be placed in a separate file next to the original file, and thus the original file does not have to be updated. With CMS signatures, what is covered by the signature is a set of attributes (unless it is a direct signature) where one of the attributes is called messageDigest, which is the hash of the original file. This means that in order to create a CMS detached signature, it is sufficient to get the hash of the original file as input.
The CMS Signer is for instance configured to accept a hash as input by setting CLIENTSIDEHASHING=TRUE, or by allowing the client to specify if the input is the original file or a hash of it, by configuring ALLOW_CLIENTSIDEHASHING_OVERRIDE=TRUE.
@@ -1751,7 +1755,7 @@
CMS Detached Signatures
-
+
Plain Signatures
For plain signatures (as produced by the
@@ -1764,14 +1768,14 @@
Plain Signatures
Explicitly specifying client-side hashing using request metadata properties:
-Works with algorithms RSASSA-PKCS1_v1.5, RSASSA-PSS, and ECDSA, for known hash algorithms and is the recommended option as of SignServer version 5.9. See Explicitly using Request Metadata Properties.
+Works with algorithms RSASSA-PKCS1_v1.5, RSASSA-PSS, and ECDSA, for known hash algorithms and is the recommended option as of SignServer version 5.9. See Explicitly using Request Metadata Properties.
-Implicitly using client-side hashing without request metadata properties:Supported for RSASSA-PKCS1_v1.5 and ECDSA but not for RSASSA-PSS. The input may also need special encoding, see Implicitly and With Encoding Depending on Algorithm.
+Implicitly using client-side hashing without request metadata properties:Supported for RSASSA-PKCS1_v1.5 and ECDSA but not for RSASSA-PSS. The input may also need special encoding, see Implicitly and With Encoding Depending on Algorithm.
-
+
RECOMMENDED Explicitly using Request Metadata Properties
We recommend explicitly specifying client-side hashing using request metadata properties. This is achieved by configuring
@@ -1799,7 +1803,7 @@
For signature formats where the signature is to be placed within the original document, additional logic has to be implemented on the client-side in order to, typically, first prepare the document for signing, compute the digest and send it to the server, and then finally embed the signature within the file.
On the client-side, support has been implemented for "client-side hashing and construction" for various signature formats (see below) for instance for Java Archives (.JAR, .APK,...) and for Authenticode signing of Portable Executable (PE) files (i.e. EXE, .DLL,..), Windows Installer files (.MSI) etc. Support for other file types such as PDF may also be implemented.
@@ -1925,7 +1929,7 @@
Embedded Signature Formats
-
+
Authenticode Signing
ENTERPRISE This is a SignServer Enterprise feature.
@@ -1975,9 +1979,17 @@
Authenticode Signing
Optional. For specifying a particular file type. If not provided SignClient will try to guess the type.
ENTERPRISE This is a SignServer Enterprise feature.
@@ -2071,7 +2083,7 @@
JAR Signing
-
+
Sample Usage
@@ -2084,7 +2096,7 @@
Sample Usage
-
+
OpenPGP Signing
ENTERPRISE This is a SignServer Enterprise feature.
@@ -2147,7 +2159,7 @@
OpenPGP Signing
-
+
Sample Usage
@@ -2162,7 +2174,7 @@
Sample Usage
-
+
Debian Dpkg-sig Signing
ENTERPRISE This is a SignServer Enterprise feature.
@@ -2222,11 +2234,11 @@
Debian Dpkg-sig Signing
You can run without the required KEY_ options and the server will give an error message that includes the values that can be used.
-
+
Algorithm Support
Note that specifically for DSA signatures in client-side mode, other algorithms than SHA1 may not be supported due to the underlying implementation.
-
+
Sample Usages
The key ID is the hex-encoded representation, and the key algorithm can be specified as either a name (RSA, DSA, or ECDSA) or using one of the PGP constant values (for example 19 for ECDSA).
@@ -2242,7 +2254,7 @@
Sample Usages
-
+
DNSSEC Signing
ENTERPRISE This is a SignServer Enterprise feature.
@@ -2326,7 +2338,7 @@
DNSSEC Signing
-
+
Sample Usages
@@ -2336,7 +2348,7 @@
Sample Usages
-
+
APPX Signing
ENTERPRISE This is a SignServer Enterprise feature.
@@ -2382,7 +2394,7 @@
APPX Signing
-
+
Sample Usages
@@ -2391,7 +2403,7 @@
Sample Usages
-
+
APK Signing
ENTERPRISE This is a SignServer Enterprise feature.
@@ -2511,11 +2523,11 @@
APK Signing
-
+
Algorithm Support
SignClient assumes the server-side signer is configured with either NONEwithECDSA, or NONEwithRSA as signature algorithm. SignClient currently supports SHA1, SHA-256, SHA-384, and SHA-512 with RSA and SHA1, SHA-224, SHA-256, SHA-384, and SHA-512 with ECDSA. DSA is not supported.
Requires client certificate authentication and that there is a rule matching one of the fields of the client's certificate in the worker's authorization list.
+
Requires client certificate authentication and that there is a rule matching one of the fields of the client's certificate in the worker's authorization list.
* if the request content-type in a POST is specified as something else than "x-www-form-urlencoded" or "multipart/form-data" the message body is not parsed but instead directly passed to the worker specified by workerName or workerId in the URI's query string.
+
* if the request content-type in a POST is specified as something else than "x-www-form-urlencoded" or "multipart/form-data" the message body is not parsed but instead directly passed to the worker specified by workerName or workerId in the URI's query string.
Configuration
@@ -1840,7 +1844,7 @@
Samples
HTTP POST with other content-type: See the TimeStampClient.
Samples of content output for certificate validation:
VALID;;This certificate is valid;-1;
-
ISSUERNOTSUPPORTED;;Issuer of given certificate isn't supported;-1;
+
ISSUERNOTSUPPORTED;;Issuer of given certificate isn't supported;-1;
REVOKED;;This certificate is revoked;3;1376565200519
If generating a symmetric (secret) key and the specified key algorithm name is not present in the predefined list of known secret key algorithms, the key algorithm name must be specified with the prefix "SEC:", for example: SEC:Blowfish. Currently, the secret key list contains the algorithms AES and DES.
If using the JackNJI11CryptoToken, the algorithm name can be specified as a long or hexadecimal constant value. For more information, see Secret Key generation in JackNJI11CryptoToken.
The signer can sign Debian packages and adds the signature in the dpkg-sig format.
-
Note that this signer uses OpenPGP and not X.509 certificates. The OpenPGP public key can instead be obtained from the worker's status output. Additionally, the generate CSR functionality allows adding a user ID to the public key and storing the new public key in the PGPPUBLICKEY worker property.
+
Note that this signer uses OpenPGP and not X.509 certificates. The OpenPGP public key can instead be obtained from the worker's status output. Additionally, the generate CSR functionality allows adding a user ID to the public key and storing the new public key in the PGPPUBLICKEY worker property.
The key management operations are the same as for the generic OpenPGP Signer.
Comma-separated list of worker names or worker IDs of workers whose keys should be tested. This would typically be crypto workers i.e. corresponding to different slots in an HSM, but could also be regular workers with crypto tokens configured directly. This property is required, but can be set to an empty value if only audit logging is needed (see below).
-
+
If secure audit logging is used and a separate crypto token is used for logging, service logging using the WORK_LOG_TYPES property and the SECURE_AUDITLOGGING value can be used to write to the audit log at the same time as testing crypto worker keys, to keep the auditlog crypto token from timing-out. For more information, see SignServer Timed Services.
The latest Apache NetBeans IDE (currently 11.2) is recommended with one exception:
-
The SignServer AdminGUI is implemented using the Swing Application Framework (JSR 296) and requires NetBeans IDE 7.0.x to allow GUI changes. Since JSR 296 didn't make it into the JDK, support for it was dropped in later versions of the IDE.
+
The SignServer AdminGUI is implemented using the Swing Application Framework (JSR 296) and requires NetBeans IDE 7.0.x to allow GUI changes. Since JSR 296 didn't make it into the JDK, support for it was dropped in later versions of the IDE.
Define the top-level project, SignServer, as the main project open in the IDE by right-clicking it and selecting Set as Main Project. This way hitting F6 will be the same as running ant deploy.
-
The downside is that F11 now maps to Build Main project and it's not convenient to rebuild everything if only working on a small number of modules. To only build the selected project (or the project belonging to the currently open file), the shortcut can be redefined to Build project.
+
The downside is that F11 now maps to Build Main project and it's not convenient to rebuild everything if only working on a small number of modules. To only build the selected project (or the project belonging to the currently open file), the shortcut can be redefined to Build project.
When deploying from within the IDE, specify the environment variable APPSRV_HOME to let the script know where to deploy to.
Ensure to specify a path to a location where SignServer can write files. The default value is empty. If a relative path is used, it is most likely relative to the application server's working directory. The directory should either point to an existing SignServer file database, or be completely empty. If the directory is empty, SignServer will create the initial database structure at startup.
+
Ensure to specify a path to a location where SignServer can write files. The default value is empty. If a relative path is used, it is most likely relative to the application server's working directory. The directory should either point to an existing SignServer file database, or be completely empty. If the directory is empty, SignServer will create the initial database structure at startup.
-The following provides an overview of SignServer's capabilities and support, with relevant links to documentation and external standards.
+The following provides an overview of SignServer's capabilities and support, with relevant links to documentation and external standards.
SignServer supports multiple application servers and standard, high-performance databases. For more information on SignServer requirements, see Prerequisites.
-
+
Algorithms
-SignServer supports the following algorithm types and key size/curves.
+SignServer supports* the following algorithm types and key size/curves.
@@ -1783,6 +1787,14 @@
Algorithms
+
+
+
EdDSA
+
+
+
Pure EdDSA with Edwards25519 or Edwards448
+
+
@@ -1809,10 +1821,13 @@
Algorithms
+
+*See individual workers and crypto tokens for information about what they support. For more information, see Signers Algorithm Support.
+
-
+
Signature Formats
-
+
Document Signing
SignServer can easily be adapted to customer-specific needs by using plug-ins and supports document signing formats such as the ones listed below.
@@ -1962,7 +1977,7 @@
Document Signing
-
+
Code Signing
SignServer supports code signing formats such as the following.
@@ -2011,6 +2026,16 @@
SignServer is used both for MRTD signing and for ICAO CSCA Master list signing.
@@ -2146,7 +2177,7 @@
ePassport
Additional algorithm support
-
+
Subject to SoW/support agreement including for instance:
@@ -2173,7 +2204,7 @@
ePassport
-
+
Time-stamping
SignServer can be used as the time stamp unit within a Time Stamp Authority (TSA) to generate digitally signed time stamps and includes monitoring of time synchronization, offering both RFC 3161 and MS Authenticode time-stamps.
@@ -2233,7 +2264,7 @@
Time-stamping
-
+
Validation Service
Validators for signed documents, built-in support for XML validation, and
@@ -2245,9 +2276,9 @@
Validation Service
-
+
Third-party Hardware
-
+
Hardware Security Modules
SignServer supports Hardware Security Modules (HSMs) and has built-in support for various HSMs such as the ones listed below
@@ -2287,18 +2318,6 @@
Hardware Security Modules
-ARX
-
-
-
-
-CoSign
-
-
-
-
-
-
nChipher
@@ -2381,7 +2400,7 @@
Hardware Security Modules
For HSM vendor specific installation and configuration information, refer to the EJBCA Documentation section Vendor Specific Information.
ENTERPRISE This is a SignServer Enterprise feature.
-
The signer has the fully qualified class name: org.signserver.module.jarchive.signer.JArchiveSigner
-
+
Overview
The signer signs Java Archives or ZIP files (.jar, .war, .ear, .apk and .zip etc) according to the JAR File Specification. The signature can optionally include a timestamp response from a TSA using the RFC#3161 format.
-
+
Available Properties
@@ -1770,7 +1771,7 @@
Available Properties
ZIPALIGN
-
True if the offset at which each file entry's data starts should be aligned to 4 bytes. Optional, default: False.
+
True if the offset at which each file entry's data starts should be aligned to 4 bytes. Optional, default: False.
@@ -1814,22 +1815,22 @@
Available Properties
-
TSA_WORKER
+
TSA_WORKER
Worker ID or name of internal (RFC#3161) timestamp signer in the same SignServer. Optional, default: none.
-Public key trusted: The worker in SignServer is configured to trust the authorization server's public key. Authorization rules matching claims from the tokens are also configured.
+Public key trusted: The worker in SignServer is configured to trust the authorization server's public key. Authorization rules matching claims from the tokens are also configured.
Credentials: The client authenticates toward the authorization server using its credentials.
diff --git a/signserver/doc/htdocs/JackNJI11CryptoToken.html b/signserver/doc/htdocs/JackNJI11CryptoToken.html
index a78e9ba521..abbc4adfd4 100644
--- a/signserver/doc/htdocs/JackNJI11CryptoToken.html
+++ b/signserver/doc/htdocs/JackNJI11CryptoToken.html
@@ -110,7 +110,7 @@
ENTERPRISE This is a SignServer Enterprise feature.
-
+
Overview
Crypto token using PKCS#11 for talking with the HSM but using a different provider than the SunPKCS11 provider used by for instance the regular PKCS11CryptoToken.
Indicates how the slot should be identified. Supported values are SLOT_NUMBER, or SLOT_INDEX. Required.
+
Indicates how the slot should be identified. Supported values are SLOT_NUMBER, SLOT_INDEX, or SLOT_LABEL. Required.
@@ -1789,9 +1793,8 @@
Available Properties
The slot to use, identified with the type specified in SLOTLABELTYPE:
SLOT_NUMBER is the number (ID) of the slot
SLOT_INDEX is the zero-base index of the slot in the list of available slots as returned by the PKCS#11 provider
+
SLOT_LABEL is the label of the slot
Required.
-
- SLOT_LABEL is currently not supported.
@@ -1801,7 +1804,7 @@
Available Properties
Specify a PKCS#11 attribute to use when generating a key.
-
Where x is the object class: PUBLIC or PRIVATE. Where y is the key type: RSA, ECDSA, etc. Where z is the attribute name or ID as decimal number, or a hexadecimal number prefixed with "0x". An exception to this is CKA_ALLOWED_MECHANISMS, which currently cannot be specified in decimal or hexadecimal form.
+
Where x is the object class: PUBLIC or PRIVATE. Where y is the key type: RSA, ECDSA, EdDSA etc. Where z is the attribute name or ID as decimal number, or a hexadecimal number prefixed with "0x". An exception to this is CKA_ALLOWED_MECHANISMS, which currently cannot be specified in decimal or hexadecimal form.
Examples:
@@ -1826,14 +1829,14 @@
Available Properties
-If true, when generating a key pair, creates a certificate object with a self-signed dummy certificate and defaults to not persist the public key object. The default value is 'true' for historical reasons and is the same as when generating a key pair with for instance the PKCS11CryptoToken (or any other Java application using the SunPKCS11 provider).
+If true, when generating a key pair, creates a certificate object with a self-signed dummy certificate and defaults to not persist the public key object. The default value is 'true' for historical reasons and is the same as when generating a key pair with for instance the PKCS11CryptoToken (or any other Java application using the SunPKCS11 provider).
-
+
This property can be set either in the crypto worker, on the worker that is going to use the key, or both, which means that different options can be used for different workers. Setting this property in the crypto token makes it the default setting for all workers using that crypto token. If the worker also includes this property, the property value of the worker will override this setting.
-
+
Be cautious if you also set any of the ATTRIBUTE.PUBLIC.*.CKA_TOKEN property attributes since some combinations like GENERATE_CERTIFICATE_OBJECT=false and CKA_TOKEN=false may not be useful, and setting both properties to true might waste space in the HSM with an unnecessary object.
@@ -1853,31 +1856,31 @@
Available Properties
-
+
Secret Key generation
If generating a secret key through the JackNJI11CryptoToken, the algorithm name can be supplied in the following ways. See also Crypto Token Generate Key Page.
-
+
Standard Java Name
Example: AES, DES.
If the specified key algorithm name is not present in the predefined list of known secret key algorithms, the key algorithm name must be specified with the prefix "SEC:", for example: SEC:Blowfish. Currently, the secret key list contains the algorithms AES and DES.
-
+
CKM Long value
Example: SEC:4224. Here 4224 represents the long value for the AES_KEY_GEN constant as per the PKCS11 specification. "SEC:" is used as prefix.
-
+
CKM Hexadecimal value
Example: SEC:0x00001080. Here 0x00001080 represents a hexadecimal value for the AES_KEY_GEN constant as per the PKCS11 specification. "SEC:" is used as prefix.
-
+
HSM Specific Notes
-
+
AWS CloudHSM
-
Configure the worker or crypto token not to generate any certificate by setting GENERATE_CERTIFICATE_OBJECT=false. For details, see the GENERATE_CERTIFICATE_OBJECT property in Available Properties.
+
Configure the worker or crypto token not to generate any certificate by setting GENERATE_CERTIFICATE_OBJECT=false. For details, see the GENERATE_CERTIFICATE_OBJECT property in Available Properties.
-
+
Known Limitations
Multiple different CA certificates with the same subject DN cannot be stored in the token (see DSS-1544).
diff --git a/signserver/doc/htdocs/JackNJI11KeyWrappingCryptoToken.html b/signserver/doc/htdocs/JackNJI11KeyWrappingCryptoToken.html
index e8b544d192..75cea20d6f 100644
--- a/signserver/doc/htdocs/JackNJI11KeyWrappingCryptoToken.html
+++ b/signserver/doc/htdocs/JackNJI11KeyWrappingCryptoToken.html
@@ -110,7 +110,7 @@
A CryptoToken using a keystore, either a PKCS#12 (.p12/.pfx), or legacy Java JKS (.jks) keystore in the local file system, or a keystore stored in the configuration (in the database).
The content of the keystore is not part of the regular worker properties. Thus, it is not included when running the dump properties command. It is also removed when removing the crypto worker (or regular worker when using the legacy method to set up crypto tokens). To backup the content of the crypto token, a database backup should be made. The password supplied when activating the token the first time will be used as the keystore password.
-
+
Special Case Type-specific Implementations
As a convenience, three type-specific implementations are available
ENTERPRISE This is a SignServer Enterprise feature.
-
+
Introduction
Key wrapping allows solving issues arising when the number of keys you need to handle exceeds the amount that can be stored in a limited storage space for an HSM. The feature enables exporting the key material in a protected manner and storing the wrapped, encrypted key in an external database.
A key-pair is generated within the HSM and the private key is wrapped (that is, encrypted with a secret key in the HSM) and exported and stored in the database. When you are going to sign with the key, the wrapped key is fetched from the database and unwrapped in the HSM, used for signing and then removed from the HSM again. Keys are thus only available in the HSM when used and only take up space in the HSM during that time.
The following displays an overview of the key wrapping operations:
-
+
The Source Crypto Worker contains a Crypto Token in order to communicate with the HSM and perform key operations. The wrapping key (secret key: aeskey001) is created in the HSM using the Source Crypto Token.
The Key Wrapping Crypto Worker contains a Key Wrapping Crypto Token in order to perform wrapped key operations. The Key Wrapping Crypto Worker references the Source Crypto Worker to get hold of HSM objects and perform key operations in the HSM.
The main operations of the Key Wrapping Crypto Token are to generate the wrapped key and to unwrap the wrapped key (using the wrapping key) in the HSM to be used for signing.
The Plain Signer references the Key Wrapping Crypto Worker in order to perform a signing operation. The Plain Signer can be configured to use either a fixed key (fixedkey01) or an individual user key (userkey1/userkey2/userkey3) depending on the requirement.
-
+
Prerequisites
The key wrapping use case requires that the key wrapping functions PKCS#11 C_WrapKey and C_UnwrapKey are supported and allowed by both the HSM and the crypto token.
The SignServer PKCS11CryptoToken uses the SunPKCS11 provider/wrapper from Java for interactions with the HSM and this provider/wrapper does not implement wrapping functions. Instead, the new P11NG provider in SignServer can be used, using the JackNJI11CryptoToken. Additionally, for the key wrapping functionality, the JackNJI11KeyWrappingCryptoToken or the JackNJI11KeyWrappingCryptoWorker can also be used.
Note that since the key material is stored in the database, this use case is not supported when running SignServer without database (also called NoDB mode).
-
+
Limitations
As of SignServer 4.3.0, the key wrapping use case has been successfully tested on the SafeNet ProtectServer Gold (HSM emulator).
While the key wrapping feature has been tested on Thales nCipher there are some open issues with stability. If using Thales nCipher, the following environment variable needs to be set:
@@ -1754,11 +1758,11 @@
Limitations
The following algorithms are supported:
-
Key algorithms: AES and RSA.
+
Key algorithms: AES, RSA and ECDSA.
Signature algorithms:
-SHAxwithRSA and SHAxwithRSAandMGF1.
+SHAxwithRSA, SHAxwithRSAandMGF1 and SHAxwithECDSA.
-
Note that Elliptic curve (i.e. ECDSA) is not yet supported.
The SignServerWS is the old web services interface now replaced by SignServer ClientWS. It was new to version 3.0 and at the time replaced the RMI-SSL interface from version 1.0 and 2.0 for two reasons, the RMI-SSL were based on a commercial library and it only worked for Java clients.
The SignServerWS WSDL file is located at the URL http://<hostname>:8080/signserver/signserverws/signserverws?wsdl
-
The interface has two calls, the main one is 'process' which takes a collection of process request to a processable worker and returns a collection of process responses, the second one is getStatus that performs a health check of the node and returns an OK message if the node is healthy.
+
The interface has two calls, the main one is 'process' which takes a collection of process request to a processable worker and returns a collection of process responses, the second one is getStatus that performs a health check of the node and returns an OK message if the node is healthy.
@@ -1740,7 +1744,7 @@
The old Web Services interface
Java Client API
-
Built along with the WebService is a Java API that can be used by clients. It's available in the file lib/SignServer-Client-SignServerWS.jar (the old SignServerWS interface) and lib/SignServer-Client-ClientWS.jar (the ClientWS interface).
+
Built along with the WebService is a Java API that can be used by clients. It's available in the file lib/SignServer-Client-SignServerWS.jar (the old SignServerWS interface) and lib/SignServer-Client-ClientWS.jar (the ClientWS interface).
SigningAndValidation API
The SigningAndValidation API is a wrapper around the previous mentioned API in order to have a simplified interface that also is the same regardless if WebService or EJB Remote calls are used.
Specifies the number of signatures allowed to be created with the same key by this worker. Default is -1 = no limit.
After the limit has been reached, the worker is considered offline.
-
+
Note that the counter is per key and not per worker. Thus, if multiple workers share the same key they will all increment the counter. This also means that the worker will be active again after it has gotten a new certificate/key.
@@ -1757,7 +1761,7 @@
Other Resources
By default, all key usages are counted, but by specifying this as TRUE, key usages performed by this worker will not be counted. Disabling the key usage counter can improve performance, as it means less database transaction. However, if you have requirements on the number of allowed signings for one worker, ensure not to use the same key with another worker for which the counter is disabled, as those uses will then be missed.
-
+
The key usage counter cannot be disabled for a worker if KEYUSAGELIMIT is also specified.
Logging: This authorizer will add the remote IP address to the log field AUTHORIZED_ADDRESS and the proxied address (if it's available in the request) in the log field AUTHORIZED_FORWARDED_ADDRESS.
+
Logging: This authorizer will add the remote IP address to the log field AUTHORIZED_ADDRESS and the proxied address (if it's available in the request) in the log field AUTHORIZED_FORWARDED_ADDRESS.
The MRTD signer has the class name: org.signserver.module.mrtdsigner.MRTDSigner.
Overview
-
The MRTD Signer performs a RSA signing operation on incoming data. The data should already be padded. This signer could be used to sign 'Machine Readable Travel Documents' i.e. electronic passports.
+
The MRTD Signer performs a RSA signing operation on incoming data. The data should already be padded. This signer could be used to sign 'Machine Readable Travel Documents' i.e. electronic passports.
ENTERPRISE This is a SignServer Enterprise feature.
The signer has the fully qualified class name: org.signserver.module.msauthcode.signer.MSAuthCodeSigner.
-
+
Overview
The MS Authenticode signer signs portable executable files such as Windows executables and shared libraries (.exe, .dll and .ocx etc) according to the Windows Authenticode Portable Executable Signature Format, and also Windows installer packages (.msi), PowerShell scripts (.ps1, .psm1 and .psd1), and Windows Catalog Files (.cat). The signature can optionally include a timestamp response from a TSA using the Authenticode or RFC#3161 format.
Note that MSI files larger than 2 GB are currently not supported.
-
+
Available Properties
@@ -1782,6 +1786,22 @@
Available Properties
If the requestor should be able to override the program URL by supplying it as a request metadata property. Optional, default: false.
+
+
+
ENCODING
+
+
+
Sets the character encoding when signing PowerShell scripts (.ps1). Optional, default: utf-8.
+
+
+
+
+
ALLOW_ENCODING_OVERRIDE
+
+
+
If the requestor should be able to override the encoding by supplying it as a request metadata property. Optional, default: false.
+
+
SIGNATUREALGORITHM
@@ -1872,7 +1892,7 @@
Available Properties
-
+
Request Properties
This worker can accept the following request metadata properties, given that they are configured to be allowed:
@@ -1905,6 +1925,14 @@
Request Properties
Program URL to use instead of the configured one (if any). Specifying an empty value removes the configured program URL. Without ALLOW_PROGRAM_URL_OVERRIDE configured in the worker request, including this request property will not be allowed.
+
+
+
ENCODING
+
+
+
Overrides the encoding when signing PowerShell scripts (.ps1). Without ALLOW_ENCODING_OVERRIDE configured in the worker request, including this request property will not be allowed.
ODF Signer, which stands for Open Document Format Signer is a plug-in to SignServer that applies server side signature to documents in ODF format. It has been tested with OpenOffice.org 3.1.
-
ODF Signer supports only "invisible" signatures, that is unlike PDF signer there's no pictorial representation of the digital signature. When you open signed document in LibreOffice you can verify signature using toolbars, or the notifier in status bar (red mark), which notifies user that the document is digitally signed.
+
ODF Signer supports only "invisible" signatures, that is unlike PDF signer there's no pictorial representation of the digital signature. When you open signed document in LibreOffice you can verify signature using toolbars, or the notifier in status bar (red mark), which notifies user that the document is digitally signed.
OOXML Signer, which stands for Office Open XML Signer is a plug-in to SignServer that applies server side signature to documents in OOXML format. It has been tested with MS Office 2007.
-
Currently OOXML Signer supports only "invisible" signatures , that is unlike PDF signer there's no pictorial representation of the digital signature.
+
Currently OOXML Signer supports only "invisible" signatures , that is unlike PDF signer there's no pictorial representation of the digital signature.
When you open signed document in MS Office you can verify signature using toolbars, or the notifier in status bar (red mark), which notifies user that the document is digitally signed.
Where "x" is the index of the archiver in the ARCHIVERS property. If this property is set to true, IP addresses in the comma-separated list given in the X-Forwarded-For header is used as the remote IP stored in the archive in case this header is set (by default the last forwarded address is used). If the header is not included, the IP address the request comes from, is used (the same behavior as when this property is not set, or set to false). This is useful when running a proxy in front of SignServer, to record the original IP address of the client, instead of the proxy's IP address. Default: false.
+
Where "x" is the index of the archiver in the ARCHIVERS property. If this property is set to true, IP addresses in the comma-separated list given in the X-Forwarded-For header is used as the remote IP stored in the archive in case this header is set (by default the last forwarded address is used). If the header is not included, the IP address the request comes from, is used (the same behavior as when this property is not set, or set to false). This is useful when running a proxy in front of SignServer, to record the original IP address of the client, instead of the proxy's IP address. Default: false.
@@ -1835,7 +1839,7 @@
-
Serial number (in hex encoding) of the client certificate (if any) used by the client.
+
Serial number (in hex encoding) of the client certificate (if any) used by the client.
This only indicates that the client certificate was used when establishing the connection to the web server, and not wether the worker required a client certificate or not, nor if it checked if the authenticated client was authorized.
Name of (crypto) worker holding (for instance) the PKCS11CryptoToken to use as the source crypto token.
-
+
When using the PKCS11CryptoToken, ensure to set CACHE_PRIVATEKEY=false as each request should use a new key pair.
@@ -1894,7 +1898,7 @@
EJBCA Peers CA Connector
SUBJECTDN_PATTERN
-
Subject DN pattern used to derive the SUBJECT DN (Distinguished Name) of the certificate to be issued. Required. Example: CN=User ${username},UID=${transactionId},O=SignServer Testing,C=SE
+
Subject DN pattern used to derive the SUBJECT DN (Distinguished Name) of the certificate to be issued. Required. Example: CN=User ${username},UID=${transactionId},O=SignServer Testing,C=SE The username is the name of the SignServer logged-in user, and the transactionId is a SignServer internal random alphanumeric number unique for each signing request.
JWT Example: CN=${JWT.firstName} ${JWT.lastName},UID=${transactionId},O=SignServer Testing,C=SE The firstName and lastName are corresponding claims of JWT token.
@@ -1904,7 +1908,7 @@
EJBCA Peers CA Connector
USERNAME_PATTERN
-
User name pattern used to derive the user name for the end entity which is registered before the certificate issuance. Required. Example: onetime-${transactionId}
+
User name pattern used to derive the user name for the end entity which is registered before the certificate issuance. Required. Example: onetime-${transactionId} The transactionId is a SignServer internal random alpha numeric number unique for each signing request.
JWT Example: onetime-${transactionId}-${JWT.iat} The iatis issued at time of JWT token.
@@ -2001,7 +2005,7 @@
EJBCA WS CA Connector
SUBJECTDN_PATTERN
-
Subject DN pattern used to derive the SUBJECT DN (Distinguished Name) of the certificate to be issued. Required. Example: CN=User ${username},UID=${transactionId},O=SignServer Testing,C=SE
+
Subject DN pattern used to derive the SUBJECT DN (Distinguished Name) of the certificate to be issued. Required. Example: CN=User ${username},UID=${transactionId},O=SignServer Testing,C=SE The username is the name of the SignServer logged-in user, and the transactionId is a SignServer internal random alpha numeric number unique for each signing request.
@@ -2050,7 +2054,7 @@
EJBCA WS CA Connector
USERNAME_PATTERN
-
User name pattern used to derive the user name for the end entity which is registered before the certificate issuance. Required. Example: onetime-${transactionId}
+
User name pattern used to derive the user name for the end entity which is registered before the certificate issuance. Required. Example: onetime-${transactionId} The transactionId is a SignServer internal random alpha numericnumber unique for each signing request.
The OpenPGPPlain signer signs arbitrary hashed data and produces a signature using NONEwithX signature algorithms (NONEwithRSA, NONEwithECDSA or NONEwithDSA) and expects that hash digest is supplied for signing not the data itself.
The signature algorithm is chosen depending on the signing key: NONEwithDSA for DSA keys, NONEwithECDSA for ECDSA keys, and otherwise NONEwithRSA. When using an RSA key, the input must be in an appropriate format, refer to RFC#3447 for details.
-
Note that this signer uses OpenPGP and not X.509 certificates. The OpenPGP public key can instead be obtained from the worker's status output. Additionally, the generate CSR functionality allows adding a user ID to the public key and storing the new public key in the PGPPUBLICKEY worker property.
+
Note that this signer uses OpenPGP and not X.509 certificates. The OpenPGP public key can instead be obtained from the worker's status output. Additionally, the generate CSR functionality allows adding a user ID to the public key and storing the new public key in the PGPPUBLICKEY worker property.
The key management operations are the same as for the generic OpenPGP Signer.
The OpenPGP signer can sign arbitrary data and produces an OpenPGP (RFC#4880) detached signature in binary or ASCII armored form or a cleartext signature.
-
Note that this type of signer does not use X.509 certificates. The OpenPGP public key can instead be obtained from the worker's status output. Additionally, the generate CSR functionality allows adding a user ID to the public key and storing the new public key in the PGPPUBLICKEY worker property.
+
Note that this type of signer does not use X.509 certificates. The OpenPGP public key can instead be obtained from the worker's status output. Additionally, the generate CSR functionality allows adding a user ID to the public key and storing the new public key in the PGPPUBLICKEY worker property.
Setting this to true in a signer uses explicit domain parameters instead of Named Curves when generating a certificate request (CSR) using the RenewalWorker or through the Admin Web Worker Page. Default: false.
-
+
The CSR must be generated from the worker and not using the Crypto Token tab.
The signer supports the addition of visible or invisible signatures. Both visible and invisible signatures serve the same purpose of signing document, and technically are equivalent in that sense. The difference is that when a visible signature is applied to a document, signature image (in the shape of a rectangle) is placed at the specified place in the document, clicking on which will allow seeing properties of the signature (Adobe Acrobat Reader).
On the other hand, when an invisible signature is applied, signature properties are accessed through menu items. For visible signatures properties such as: custom signature image, signature rectangle, page at which signature rectangle to be drawn and others can be specified (see Worker Properties).
PDF Signer can also apply a timestamp to a signature. If the signature is timestamped, it can be viewable through signature properties in Adobe Acrobat Reader. Timestamping is used to prove that the document was signed before the time specified by the timestamp token. If the signature is not timestamped then the signature time specified in the signature properties is not considered to be trusted. It is strongly advised to apply a timestamp to a signature, and the TSA module can be used for this purpose.
-
Also, CRL or OCSP Response of the signer's certificate can be embedded inside the signature package. Embedding CRL or OCSP response with the package will help validate the signature even after the signer's certificate is expired. (Though it will not guarantee the long-term signature preservation. The topic of long-term signature preservation for archival purposes is a large one and is discussed to be implemented in future versions of SignServer).
+
Also, CRL or OCSP Response of the signer's certificate can be embedded inside the signature package. Embedding CRL or OCSP response with the package will help validate the signature even after the signer's certificate is expired. (Though it will not guarantee the long-term signature preservation. The topic of long-term signature preservation for archival purposes is a large one and is discussed to be implemented in future versions of SignServer).
The PDF Signer can also be configured to enforce that certain PDF permissions are not available in the signed document and/or that certain permissions should be removed.
@@ -1816,12 +1820,12 @@
Worker Properties
If you want the visible signature to contain a custom image, specify image as base64 encoded byte array. Alternatively, the custom image can be specified by giving a path to the image on the file system.
-
+
If specifying a path to an image, "\" should be escaped (thus C:\photo.jpg => "C:\\photo.jpg").
-
+
If specifying image as base64 encoded byte array, "=" should be escaped (thus "BBCXMI==" => "BBCXMI\=\=").
If both properties are set, VISIBLE_SIGNATURE_CUSTOM_IMAGE_BASE64 will take priority. To disable the feature, do not set the properties. Default: not set (no custom image). These properties are ignored if ADD_VISIBLE_SIGNATURE is set to False.
-
+
Note that in a clustered environment, it is advised to specify image as base64 string, since image data will be stored in a central database. Otherwise, each node should contain a copy of the image, and each image managed separately (e.g. on image updates, or insertion of a new image for a different worker).
If you want the custom image to be resized to a specified rectangle (set by VISIBLE_SIGNATURE_RECTANGLE), then set to True. If set to True, the image might look different than the original (as an effect of resizing). If set to False, the rectangle drawn will be resized to the specified image's sizes. If set to False, the llx and lly coordinates specified by the VISIBLE_SIGNATURE_RECTANGLE property will be used for drawing the rectangle (urx and ury will be calculated from the specified image size). This property is ignored if ADD_VISIBLE_SIGNATURE is set to False, or if the custom image to use is not specified. Possible values: True, False. Default: True.
+
If you want the custom image to be resized to a specified rectangle (set by VISIBLE_SIGNATURE_RECTANGLE), then set to True. If set to True, the image might look different than the original (as an effect of resizing). If set to False, the rectangle drawn will be resized to the specified image's sizes. If set to False, the llx and lly coordinates specified by the VISIBLE_SIGNATURE_RECTANGLE property will be used for drawing the rectangle (urx and ury will be calculated from the specified image size). This property is ignored if ADD_VISIBLE_SIGNATURE is set to False, or if the custom image to use is not specified. Possible values: True, False. Default: True.
@@ -1847,9 +1851,9 @@
Worker Properties
If we want to timestamp document signature, specify timestamp authority URL. This will cause time stamp requests to be issued via HTTP requests. Under high load, this can lead to thread deadlocks in the application server if using a localhost URL (using a time stamp signer running in the same server). In this case, use the internal mechanism described below). To not timestamp document signature, do not set the property.
-
+
If path contains characters "\" or "=" , these characters should be escaped (thus "\" = "\\", "=" =>"\=").
Specify a worker ID or worker name for a time stamp signer This will use internal calls and can only be used for a time stamp authority running in the same SignServer instance.
-
+
Use instead of TSA_URL when using a time stamp signer running in the same SignServer instance to avoid thread deadlocks under high load.
To embed the OCSP response for the signer certificate inside the signature package, set to True, otherwise set to False.
-
- Issuer certificate (of signing certificate) should be in certificate chain.
+
+ Issuer certificate (of signing certificate) should be in certificate chain.
OCSP responses must contain a nextUpdate field in order for offline validation to work with Adobe Reader. For EJBCA OCSP Responder, see configuration of ocsp.untilNextUpdate in ocsp.properties.
Default: False.
@@ -1965,9 +1969,9 @@
Worker Properties
SET_PERMISSIONS
-
Replace the current permissions (if any) with the permissions specified in this comma-separated list of permissions. Available permissions: The same permission names as for the property REJECT_PERMISSIONS.
- This property cannot be specified if REMOVE_PERMISSIONS is used.
- This property and the REMOVE_PERMISSIONS property only set the permissions setting in the document. All permissions might not be enforced by the PDF reader, and some permissions specified to be allowed by this property, might not be allowed when opening the final document (i.e. if that would invalidate the signature and/or certification).
+
Replace the current permissions (if any) with the permissions specified in this comma-separated list of permissions. Available permissions: The same permission names as for the property REJECT_PERMISSIONS.
+ This property cannot be specified if REMOVE_PERMISSIONS is used.
+ This property and the REMOVE_PERMISSIONS property only set the permissions setting in the document. All permissions might not be enforced by the PDF reader, and some permissions specified to be allowed by this property, might not be allowed when opening the final document (i.e. if that would invalidate the signature and/or certification).
If the document is not already protected by an owner password and the SET_OWNERPASSWORD is not specified, a random password will be used as owner password. Default: Unset (permissions are not set by this property)
@@ -1976,8 +1980,8 @@
Worker Properties
REMOVE_PERMISSIONS
-
Remove all permissions specified in this comma-separated list from the document. Available permissions: The same permission names as for the property REJECT_PERMISSIONS. This property can not be specified if SET_PERMISSIONS is used.
- This property only removes the permissions listed even if some permissions (i.e. ALLOW_PRINTING) by the standard gives more permissions (i.e. also ALLOW_DEGRADED_PRINTING). To remove all permissions to print remove both ALLOW_PRINTING and ALLOW_DEGRADED_PRINTING. To still have ALLOW_DEGRADED_PRINTING it is possible to specify to only remove ALLOW_PRINTING. See
+
Remove all permissions specified in this comma-separated list from the document. Available permissions: The same permission names as for the property REJECT_PERMISSIONS. This property can not be specified if SET_PERMISSIONS is used.
+ This property only removes the permissions listed even if some permissions (i.e. ALLOW_PRINTING) by the standard gives more permissions (i.e. also ALLOW_DEGRADED_PRINTING). To remove all permissions to print remove both ALLOW_PRINTING and ALLOW_DEGRADED_PRINTING. To still have ALLOW_DEGRADED_PRINTING it is possible to specify to only remove ALLOW_PRINTING. See
notes for REMOVE_PERMISSIONS which also applies to this setting. Removing only ALLOW_DEGRADED_PRINTING has no effect, as degraded printing is implicitly allowed if printing is allowed. Default: Unset/empty (no permissions are removed)
@@ -2067,8 +2071,8 @@
Worker Properties
-
By default, the PDF Signer requires the owner's password to sign a PDF that has PDF permissions set.
-
Setting ALLOW_SIGNING_WITHOUT_OWNERPASSWORD to true allows signing a protected PDF without providing the owner's password. The property is by default set to false for backward compatibility.
+
By default, the PDF Signer requires the owner's password to sign a PDF that has PDF permissions set.
+
Setting ALLOW_SIGNING_WITHOUT_OWNERPASSWORD to true allows signing a protected PDF without providing the owner's password. The property is by default set to false for backward compatibility.
The key alias of the private key to be used for testing that this crypto token is working.
-
+
If this key does not exist, the crypto token/worker will show as OFFLINE even if it has been activated. This is typically the case when the crypto token has been set up for the first time and the key has not yet been generated. To resolve, generate a key with the key alias name.
A property with this name is typically also accepted by the worker using this crypto token and will then be the key to use for actual signing.
@@ -1787,7 +1791,7 @@
Available Properties
SHAREDLIBRARY
-
+
This property is deprecated.
Full path to the library containing the PKCS11 interface. From version 3.7.0 this must point to a file declared in signserver_deploy.properties (or using the built-in values). If this property is defined at the same time as SHAREDLIBRARYNAME they must point to the same library on the file system.
@@ -1854,10 +1858,10 @@
Available Properties
}
-
+
The PKCS#11 attributes configuration is global per shared library. If specified in multiple workers, only the configuration from the first worker loaded will be used. Changing the property might not take effect without restarting the application server.
-
- For a Thales nCipher 'module protected' slot (slot index 0), CKA_PRIVATE must be false for the CKO_PRIVATEKEY to allow the key to be used without a login. Otherwise the key generation will fail with a CKR_USER_NOT_LOGGED_IN PKCS#11 error.
+
+ For a Thales nCipher 'module protected' slot (slot index 0), CKA_PRIVATE must be false for the CKO_PRIVATEKEY to allow the key to be used without a login. Otherwise the key generation will fail with a CKR_USER_NOT_LOGGED_IN PKCS#11 error.
This feature requires a patched Java Runtime Environment.
@@ -1886,9 +1890,9 @@
Available Properties
If set to true, the private key and certificate is cached in the worker so that they are not queried for each signature. This could potentially improve performance in some environments, typically where network HSMs or HSM slots with many keys are used. Default: true.
-
+
This worker property is to be specified in the worker where the key to be used is specified by the DEFAULTKEY property. It is that key that will be cached locally in the worker. It is important to remember this if the crypto token is configured in a separate worker in which case this property should be specified in the worker that will be using the crypto token and not necessarily in the one having the crypto token configuration.
-
+
When enabled, the signer certificate is also cached if taken from the token and not overridden by specifying it in the configuration. This means that if the certificate in the token is changed, the old certificate will still be used until the worker is reloaded, clearing the cache.
Generally, the instance with higher security requirements (for example, an EJBCA acting as CA) initiates connections to a system with lower security requirements (for example, a SignServer instance or an EJBCA acting as VA or RA). SignServer currently only implements support for incoming peer connections.
Peer Systems for Certificate Renewal
-
SignServer can be configured to expose the worker's keys as Remote Key Bindings in EJBCA. This allows the EJBCA administrators to issue new certificates to workers in SignServer directly from within the EJBCA interface, without incoming network connections to the CA.
+
SignServer can be configured to expose the worker's keys as Remote Key Bindings in EJBCA. This allows the EJBCA administrators to issue new certificates to workers in SignServer directly from within the EJBCA interface, without incoming network connections to the CA.
For instructions on how to set up the systems for certificate renewal using peer systems, see Certificate Renewals Using Peer Systems. Alternatively, see Renewal Worker, which instead of Peer Systems uses the EJBCA web services interface and connects to the CA.
Mapping SignServer Workers to Remote Key Bindings in EJBCA
@@ -1834,7 +1838,7 @@
Worker Properties
Indicates that the current key has been issued by the peer system.
When enabled, SignServer will include the fingerprint of the current certificate and EJBCA will only display the remote key binding if it has the issuer of the certificate. For that reason, before the worker has got its first certificate from the peer, this value should be false so that the key binding will be listed on the EJBCA side. After the certificate has been issued, the property will automatically be changed to true. Default: false.
-
+
This property should normally not have to be changed manually.
The Plain signer has the fully qualified class name: org.signserver.module.cmssigner.PlainSigner
-
+
Overview
The Plain signer can sign arbitrary data and simply produces a signature in the format determined by the configured signature algorithm.
-
+
Available Properties
@@ -1751,7 +1755,7 @@
Available Properties
SIGNATUREALGORITHM
-
Property specifying the algorithm used to sign the data. Default value depends on the signing key: SHA256withDSA for DSA keys, SHA256withECDSA for ECDSA keys, otherwise SHA256withRSA.
+
Property specifying the algorithm used to sign the data. Default value depends on the signing key: SHA256withDSA for DSA keys, SHA256withECDSA for ECDSA keys, Ed25519 or Ed448 for EdDSA keys, otherwise SHA256withRSA.
Client-Side Hashing:
For Client-Side Hashing, use one of the NONEwith... signature algorithm values and either use CLIENTSIDEHASHING=true or ALLOW_CLIENTSIDEHASHING_OVERRIDE=true, or alternatively make sure the input is encoded in the expected way for the chosen signature algorithm.
Specifically for NONEwithRSA (RSASSA-PKCS1-v1.5) and if those properties are not set, then the input needs to be encoded according to RFC#3447. Note that this is the legacy way of configuring client-side hashing with the plain signer. As of SignServer 5.9, it is recommended to instead use one of the CLIENTSIDEHASHING and ALLOW_CLIENTSIDEHASHING_OVERRIDE properties, as the client then does not have to care of any special encoding.
@@ -1809,7 +1813,7 @@
Available Properties
-
+
Request Parameters
The following meta data parameters can be specified in a request
The following lists supported algorithms that are tested and known to work with a Crypto Token supporting it and therefore the list may not be complete.
Update the crypto token's KEYSTOREPATH property to point to a PKCS#12 keystore containing keys and certificate suitable for timestamp signing (the sample keystore in res/test/dss10/dss10_keystore.p12 can be used). Update the keystore password and set the crypto token's default key:
+
Update the crypto token's KEYSTOREPATH property to point to a PKCS#12 keystore containing keys and certificate suitable for timestamp signing (the sample keystore in res/test/dss10/dss10_keystore.p12 can be used). Update the keystore password and set the crypto token's default key:
Update the crypto token's KEYSTOREPATH property to point to a PKCS#12 keystore containing keys and certificate suitable for document signing (the sample keystore in res/test/dss10/dss10_keystore.p12 can be used). Update the keystore password and set the crypto token's default key.
+
Update the crypto token's KEYSTOREPATH property to point to a PKCS#12 keystore containing keys and certificate suitable for document signing (the sample keystore in res/test/dss10/dss10_keystore.p12 can be used). Update the keystore password and set the crypto token's default key.
A typical setup with automatic renewal contains at least the following workers.
Crypto Worker
-
The worker holding the crypto token. Configured as usual, but needs to be separated from the worker that will be renewed, in order not to be deactivated when the worker's configuration changes during the renewal.
+
The worker holding the crypto token. Configured as usual, but needs to be separated from the worker that will be renewed, in order not to be deactivated when the worker's configuration changes during the renewal.
Fully qualified class name: org.signserver.module.renewal.worker.RenewalWorker.
Overview
-
The RenewalWorker can be used for generating a new key-pair and renewing a worker's certificate from EJBCA using web services (WS). The RenewalWorker should be configured with its own CryptoToken and an SSL client authentication certificate with permissions set up in EJBCA to issue certificates. Some properties are configured for the RenewalWorker, such as the EJBCA WS endpoint URL and truststore details, and other properties should be set on the worker to be renewed (the renewee) and some arguments are provided when the worker is invoked.
+
The RenewalWorker can be used for generating a new key-pair and renewing a worker's certificate from EJBCA using web services (WS). The RenewalWorker should be configured with its own CryptoToken and an SSL client authentication certificate with permissions set up in EJBCA to issue certificates. Some properties are configured for the RenewalWorker, such as the EJBCA WS endpoint URL and truststore details, and other properties should be set on the worker to be renewed (the renewee) and some arguments are provided when the worker is invoked.
Note the known limitation that it might not be possible to have multiple renewal workers using different crypto tokens, since the keys and certificates used by the TLS connection for the web service is setup globally.
@@ -1751,7 +1755,7 @@
Requesting the worker
AUTHCODE=foo123"
-
+
Note that the command is on two lines.
Using the Admin CLI to initiate the renewal:
@@ -1794,7 +1798,7 @@
Worker Properties
TRUSTSTOREPATH
-
Path to the keystore containing the CA's SSL server certificate as a trusted entry. Used instead of TRUSTSTOREVALUE. If this property is not specified, TRUSTSTOREVALUE must be set.
+
Path to the keystore containing the CA's SSL server certificate as a trusted entry. Used instead of TRUSTSTOREVALUE. If this property is not specified, TRUSTSTOREVALUE must be set.
@@ -1802,7 +1806,7 @@
Worker Properties
TRUSTSTOREVALUE
-
Keystore containing the CA's SSL server certificate as a trusted entry. Used instead of TRUSTSTOREPATH. If this property is not specified, TRUSTSTOREPATH must be set. If TRUSTSTORETYPE is not PEM, the keystore is stored in the property in base64 encoding.
+
Keystore containing the CA's SSL server certificate as a trusted entry. Used instead of TRUSTSTOREPATH. If this property is not specified, TRUSTSTOREPATH must be set. If TRUSTSTORETYPE is not PEM, the keystore is stored in the property in base64 encoding.
Fully qualified class name: org.signserver.module.tsa.RequestedPolicyDispatcher
Overview
-
Dispatches the time-stamp request to an other signer based on the requested TSA Policy according to an configured mapping table. This dispatcher can be useful if you want to have multiple signers (Timestamp Units) signing with different TSA policies but don't want the client to have to call different workers.
+
Dispatches the time-stamp request to an other signer based on the requested TSA Policy according to an configured mapping table. This dispatcher can be useful if you want to have multiple signers (Timestamp Units) signing with different TSA policies but don't want the client to have to call different workers.
See also the DispatchedAuthorizer which if configured by a signer can allow all requests that has gone through a Dispatcher.
@@ -1776,7 +1780,7 @@
Available Properties
INCLUDESTATUSSTRING
-
Specifies if the status string is to be included in the response. This setting only affects the behavior when USEDEFAULTIFMISMATCH is false, and there is no mapping for the requested policy. In case there is a mapping (or no mapping and USEDEFAULTIFMISMATCH is true), the state of INCLUDESTATUSSTRING of the used signer is used to determine if the status string is included. Setting this to true triggers a bug in some versions of OpenJDK's jarsigner utility. (OPTIONAL), default true.
+
Specifies if the status string is to be included in the response. This setting only affects the behavior when USEDEFAULTIFMISMATCH is false, and there is no mapping for the requested policy. In case there is a mapping (or no mapping and USEDEFAULTIFMISMATCH is true), the state of INCLUDESTATUSSTRING of the used signer is used to determine if the status string is included. Setting this to true triggers a bug in some versions of OpenJDK's jarsigner utility. (OPTIONAL), default true.
-
+
Version 0.9 or later of the apksigner tool is required as previous versions had issues if the APK contained a v3 signature.
@@ -1988,7 +1992,7 @@
Setting up Workers for Key Rotation
to allow inspecting the lineage file and optionally update it.
-
+
Make sure to set the appropriate authentication (AUTHTYPE) of each worker in order to prevent unauthorized usage of the signers. For more information, see Authorization Type.
+The SignServer team is pleased to announce the release of SignServer 5.10. This release adds support for the EdDSA signature scheme, key wrapping for Elliptic Curves, and post-quantum signing with the SPHINCS+ algorithm candidate implementation in Bouncy Castle.
+
+The Edwards-curve Digital Signature Algorithm (EdDSA) is gaining increased traction and enables a high level of security and performance even on resource-constrained devices. SignServer 5.10 introduces support for generating EdDSA signatures and t
+
+he algorithms
+
+Ed25519 and Ed448 are now supported in the Plain signer, CMS signer, and Time Stamp signer. Use of the EdDSA algorithms requires utilizing the P11NG crypto token as well as HSM support for the selected algorithm.
+
+
+
+
Key Wrapping Support for Elliptic Curves
+
+The SignServer key wrapping feature was previously limited to RSA keys. As of SignServer 5.10, key wrapping is supported also for EC keys. Use of the key wrapping feature requires utilizing the P11NG crypto token. For more information, see Key Wrapping.
+
+
+
+
Post-quantum Signing with upgraded SPHINCS+ Algorithm and new Bouncy Castle version
+
+SignServer enables you to prepare for quantum-safe signing by using the NIST Post-Quantum Cryptography (PQC) candidate algorithm SPHINCS+ through Bouncy Castle. Using the CMS Signer and the Keystore Crypto Token together with the SPHINCS+ algorithm allows you to experiment with creating post-quantum keys and signatures. For more information, see the Post-quantum Code Signing How-to.
+
+
+SignServer 5.10 has upgraded the Bouncy Castle version to 1.71.1 which includes support for the SPHINCS+ v3.1 algorithm.
+
-
-ZoneZipSigningAlgorithmTest does not verify the signature at 'fixed time' causing test failure
+ZoneZipSigningAlgorithmTest does not verify the signature at 'fixed time' causing test failure
DSS-2072 - Expired certificate in junit tests causes test failures
DSS-2090 - Zone file signing test failures with NoClassDefFoundError after merge to trunk
The SignServer team is pleased to announce the release of SignServer 5.9.1. This release includes improvements for integration with AWS CloudHSM as well as new versions of OpenPDF and Bouncy Castle and other minor improvements and corrections.
+
The SignServer team is pleased to announce the release of SignServer 5.9.1.
+
This release includes improvements for the integration with AWS CloudHSM. The release also brings new versions of OpenPDF and Bouncy Castle and other minor improvements and corrections.
New flexibility of the P11NG crypto token now allows P11NG to be used with SignServer for integration with AWS CloudHSM. A new setting on a worker or the crypto token can control if a certificate object is generated when a key pair is generated. When used for integration with AWS CloudHSM, the worker or crypto token must be configured not to generate certificates. A similar option is also available in the p11-ng tool (using the nocertificateobject command).
+
New flexibility of the P11NG crypto token now allows P11NG to be used with SignServer for integration with AWS CloudHSM. A new setting on a worker or the crypto token can control if a certificate object is generated when a key pair is generated. When used for integration with AWS CloudHSM, the worker or crypto token must be configured not to generate certificates,
+using the JackNJI11CryptoToken
+
+property GENERATE_CERTIFICATE_OBJECT
+. A similar option is also available in the p11-ng tool (using the nocertificateobject flag).
Further improvements to the Android (APK) signers have been made in this release making the APK signers work fully without certificates in the token and thus function with AWS CloudHSM.
SignServer Release Notes provide information on features and improvements implemented in each release. The Release Notes also include a change log, listing all issues resolved in the release and a cross-reference to our JIRA Issue Tracker for full details on issues resolved in the release.
The following summary lists release notes for all SignServer versions.
For detailed information on features and improvements implemented per release, see the SignServer Release Notes. The SignServer Release Notes also include a change log, listing all issues resolved in the release and a cross-reference to our JIRA Issue Tracker for full details on issues resolved in the release.
AWS CloudHSM Improvements:
+ New flexibility of the P11NG crypto token now allows P11NG to be used with SignServer for integration with AWS CloudHSM. A new setting on a worker or the crypto token can control if a certificate object is generated when a key pair is generated. When used for integration with AWS CloudHSM, the worker or crypto token must be configured not to generate certificates,
+
+
+using the
+ JackNJI11CryptoToken
+
+property GENERATE_CERTIFICATE_OBJECT. A similar option is also available in the
+ p11-ng tool (using the nocertificateobject flag). Further improvements to the Android (APK) signers have been made in this release making the APK signers work fully without certificates in the token and thus function with AWS CloudHSM.
+
+Bouncy Castle Upgradedto Latest Version:
+
+Bouncy Castle is upgraded to version 1.71.
+
+
+OpenPDF Upgraded to Latest Version:
+
+OpenPDF is upgraded to version 1.3.28.
+
+
+
SignServer 5.9.0
@@ -1800,14 +1828,14 @@
SignServer 5.9.0
nor the subsequent findings due to the fact that SignServer handles logging through JBoss EAP/WildFly, merely facilitated by the Log4j API. Log4j version 1 has been included in the source mainly as a building block and not used in the main deployment, and is only ever directly referenced from the CLI, but will hence still trip automatic vulnerability scanners. As we understand that some of our customers need to comply with auditors and other regulatory authorities, we have decided to accelerate the planned upgrade of Log4j to the latest release in order to dissolve any questions about SignServer being vulnerable.
-
+
SignServer 5.8.2
SignServer 5.8.2 was an internal release, not generally available for customers.
-
+
SignServer 5.8.1
S
@@ -1836,7 +1864,7 @@
SignServer 5.8.1
Severity:Low – Only an authorized SignServer administrator could perform an attack. Any update of worker names configured in SignServer will be logged in the audit log.
-
+
SignServer 5.8.0
@@ -1855,7 +1883,7 @@
SignServer 5.8.0
SignServer 5.8 brings improvements for managing long-term archiving of signed documents. For eIDAS Advanced level signing using PAdES and XAdES signature formats, SignServer now supports extending the validity of a document with a previous signature. In addition, the AdES signer has been improved to handle larger signature sizes. For more information, see AdES Signer.
-
+
SignServer 5.7.0
@@ -1885,14 +1913,14 @@
SignServer 5.7.0
SignServer 5.7 adds support for RSASSA-PSS with client-side hashing (NONEwithRSAandMGF1) similar to what has been supported in previous versions for NONEwithRSA. The RSASSA-PSS algorithm requires use of the P11NG provider (JackNJI11CryptoToken). For more information, see Client-Side Hashing.
-
+
SignServer 5.6.1
This minor release brings improvements for the SHAxWithRSAandMGF1 / RSASSA-PSS algorithms on certain Java versions. These improvements are required in certain customer deployments due to the Java Virtual Machine (JVM) implementations.
-
+
SignServer 5.6.0
@@ -1910,10 +1938,10 @@
SignServer 5.6.0
For information on configuring and signing using the SignServer MS Authenticode signer, see Authenticode Code Signing.
-
+
SignServer 5.5.0
-
+
General
Authenticode Signing of Microsoft PowerShell Scripts: SignServer Enterprise supports
@@ -1931,29 +1959,29 @@
General
-
+
SignServer 5.4.0
-
+
General
Azure Key Vault Support: A new Crypto Token implementation now allows storing and using the signing keys in Azure Key Vault, see AzureKeyVaultCryptoToken.
JSON Web Token Authorizer: A new Authorizer implementation makes it possible to allow signature requests based on the provided JSON Web Token (JWT) included in the request, see JWT Authorizer.
Custom Folder for Configuration: A separate signserver-custom folder, outside of the SignServer home folder, now enables easier upgrades since you no longer need to copy your old configuration. For more information, see Install SignServer.
-
+
SignServer 5.3.0
-
+
General
APPX Signing: SignServer Enterprise now supports APPX signing using the new signers Appx Signer and Appx CMS Signer.
New and Improved Client Web
@@ -1964,20 +1992,20 @@
General
-
+
SignServer 5.1.0
-
+
General
Improved Client Certificate Authorization
PGP Signing Support
Debian Package Signing Support
-
+
SignServer 5.0.0
-
+
General
Upgraded libraries and internal dependencies
Support for running on WildFly 14 and JBoss EAP 7
@@ -1985,41 +2013,41 @@
General
Restructured and improved installation guide and release information
-
+
SignServer 4.4.1
-
+
General
New Authorizer component for logging cookies from the request
Improvements to startup scripts
-
+
SignClient
While SignServer still requires Java 7 or 8, the Client command line interface (SignClient) can now additionally also be run on Java 11.
Error handling improvements
-
+
SignServer 4.3.2
-
+
General
New authorizer for logging cookies from the request
-
+
Time-stamping
Performance test CLI now uses SHA-256 for the time-stamp request
-
+
SignServer 4.4.0
-
+
New features and improvements
Support for on-demand generated one-time keys with short-lived certificates issued from EJBCA.
12 other minor improvements
-
+
Bug fixes
Time-stamp hash algorithm used by XAdESSigner should be configurable
Error with MSI signing when certificate not installed in token
@@ -2028,21 +2056,21 @@
Bug fixes
7 other bug fixes
-
+
SignServer 4.3.1
-
+
General
Sensitive information masked in status output, configuration and logs.
-
+
Administration Web
-
New possibility to easily select 'all' in the tables.
+
New possibility to easily select 'all' in the tables.
Improved certificate export page.
Character encoding handled correctly when importing configuration.
A number of other minor bug fixes or improvements.
-
+
Configuration and Deployment
Key usage counter disabled by default in sample configuration files.
Fixed typos in sample configuration files.
@@ -2050,24 +2078,24 @@
Configuration and Deployment
Fixed deployment issue with Ant version 1.10.2.
CLI scripts for Windows updated or added were missing.
-
+
Time-stamping
Fixed regression with key usage counter and signer validity checks in some situations.
Tokens are verified after signing to ensure the right key/certificate is used.
Improved error reporting in TimeMonitor when an incorrect time server is configured.
TimeMonitor now picks the results chosen by ntpdate when multiple are available.
-
Removed redundant 'Accuracy' field in the SignClient output.
+
Removed redundant 'Accuracy' field in the SignClient output.
-
+
Code Signing
Fixed error message in SignClient when file type could not be determined.
SignClient in client-side mode now properly refuses already Authenticode signed files.
-
+
SignServer 4.3.0
-
+
New features and improvements
SignClient Server Failover and Loadbalancing
Strong Algorithms by Default
@@ -2075,26 +2103,26 @@
New features and improvements
New Alternative PKCS#11 Provider (experimental)
Utimaco HSM in FIPS Mode Support
-
+
Bug fixes
Regression Worker lockup under high load when database interactions was configured.
SOD Signer was not including NULL parameter for RSASSA-PKCS1 signature as required by ICAO.
-
+
SignServer 4.2.2
-
+
Bug fixes
Signing is no longer initialized if it is going to be refused in TimeStampSigner.
Signing is no longer initialized if it is going to be refused in MasterListSigner.
An out of memory issue in the the database CLI command was fixed.
-
+
SignServer 4.2.1
-
+
New features and improvements
Use a signature algorithm supported by HSM for test signing
Tested with WildFly 10, JBoss EAP 7 and Java 8
@@ -2102,7 +2130,7 @@
New features and improvements
Documentation improvements
9 other features or improvements
-
+
Bug fixes
SignClient on Windows was missing some new enterprise features
Error after importing certificate using explicit ECC parameters
@@ -2112,124 +2140,124 @@
Bug fixes
18 other bug fixes
-
+
SignServer 4.2.0
-
+
Featured Features
Rekeying from EJBCA using Peer Connectors.
Client-side hashing for Authenticode and JAR signing.
-
+
General
Bouncy Castle and CESeCore libraries updated.
Fixed translation issues.
New PrimeKey logos.
-
+
Code Signing
Authenticode signing with client-side hashing.
JAR signing with client-side hashing.
One issue with duplicated signature names fixed for JAR signing.
-
+
Bug Fixes
One issue with SignClient exit code fixed.
-
+
SignServer 4.1.1
-
+
Time-stamping
Legacy option to encode the time-stamp tokens as before Bouncy Castle 1.50.
Legacy option to not include the RFC#6211 cmsAlgorithmProtection attribute in the token.
-
+
PDF Signing
Issue with PDF version if digest specified as SHA-256 instead of SHA256 resolved. Fix contributed by Aziz Göktepe.
-
+
Admin Web
A number of translation issues fixed.
-
+
Bug fixes
There was 7 issues fixed.
-
+
SignServer 4.1.0
-
+
Major Features
A brand new administration web interface.
Support for signing Windows Installer (MSI) packages.
-
+
General Signing
Support for hashing on the client side for CMS/PKCS#7 detached signatures.
-
+
Code Signing
Added MSI signing support.
Performance: Option to disable request hashing in the Plain Signer.
-
+
ePassport
Adapted CMS Signer to be suitable for signing ICAO Deviation Lists.
-
+
Time-stamping
Added sample init.d script for running the SignServer TimeMonitor.
-
+
Documentation
Restructured and improved documentation.
Improved Javadoc for the AdminWS and ClientWS interfaces.
-
+
Security
Further security hardening of the web applications including Content Security Policy headers and HttpOnly cookie protection.
Removed a potential cross site scripting vulnerability on the public web only affecting a set up with the TimeMonitorManager and normally restricted to authenticated users only.
Libraries has been upgraded.
-
+
Bug Fixes
There was 16 issues fixed.
-
+
SignServer 4.0.2
-
+
New features
Support for configurable content OID in CMS signatures
Support for DER encoding of CMS signatures
-
+
Bug fixes
Master list signer was only working with certificate installed in token
Issues with PDF permissions when PDF version gets upgraded
Regression: TimeMonitor manual was not available in the SignServer manual
-
+
SignServer 4.0.1
-
+
New features
Support for RFC 3161 timestamps in the Authenticode signer
Ability to download integration CLI in the same way as the Admin GUI
-
+
Improvements
Performance improvements
Additional PKCS#11 library definitions
Make inclusion of IssuerSerial in SigningCertificate in Time-stamp tokens optional
Security hardening
-
+
Bug fixes
A security issue
ClassCastException trying to test key from Admin GUI running against local SignServer instance
@@ -2240,10 +2268,10 @@
Bug fixes
Wrong icon for crypto workers in admin GUI
-
+
SignServer 4.0.0
-
+
Major new features and improvements
Support for large files (Enterprise Edition)
Major internal library updates such as CESeCore 6.4 and BouncyCastle 1.53
@@ -2252,7 +2280,7 @@
Major new features and improvements
Support for RFC 5816 time-stamps
Initial Payara 4.1 support
-
+
Bug fixes
Bug in BouncyCastle related to extensions in time-stamps
ClientWS interface did not handle X-Forwarded-For header
@@ -2261,18 +2289,18 @@
Bug fixes
Fixed stylesheet on public web pages
-
+
SignServer 3.7.4
-
+
New feature
Support for qcStatements extension for Qualified Electronic Time-stamps
-
+
Improvement
More reliable calculation of free memory in Health Check
-
+
Bug fixes
Fixed issue with PostgreSQL
Fixed archive querying when running the GUI locally
@@ -2280,29 +2308,29 @@
Bug fixes
A few documentation and sample configuration fixes
-
+
SignServer 3.7.3
The renewsigner admin CLI command will no longer prompt for an authcode when the -authcode CLI argument is omitted, use the new -authprompt option to get an interactive prompt. When the authcode is not given (or prompted for), the command will not automatically (re)activate the token.
-
+
SignServer 3.7.2
-
+
Bug fixes
Performance: Cache key option now improves performance with network HSM
Performance: The response time is improved on some systems
-
+
SignServer 3.7.1
-
+
New features
Java code signing support (including Android).
Support for key generation with custom RSA public exponent.
-
+
Improvements
Support for large files in Client CLI.
Minor performance improvements.
@@ -2311,7 +2339,7 @@
Improvements
Administration GUI improvements.
Improved language in the manuals.
-
+
Bug fixes
Security issue in Commons Collections library.
Regression: Renewing keys for multiple workers at once did not fully work in the Administration GUI.
@@ -2321,30 +2349,30 @@
Bug fixes
24 other bug fixes.
-
+
SignServer 3.7.0
-
+
New features
Indivual keys. Key aliases in crypto tokens can be selected by workers at run-time based on the incoming request using the new AliasSelector interface. An implementation selecting aliases based on the authenticated user of the request is included.
-
+
Bug fixes
Crypto token operations in the administration GUI no requires clicking outside of the last edited input field to be able to perform the action (i.e. when generating keys).
-
+
SignServer 3.6.3
-
+
New Features and Improvements
Authenticode signer for portable executables (enterprise edition only).
CSCA Master List Signer (enterprise edition only).
Signer that produces plain signatures.
Configurable maximum upload limit.
-
+
Bug fixes
Key test results now displays correctly in audit log.
Database tables now only listed once during deployment.
@@ -2353,33 +2381,33 @@
Bug fixes
Dispatchers status page now lists configuration errors.
-
+
SignServer 3.6.2
-
+
Bug fixes
Security issue in XML workers
Regression: Menu command for activating workers not working properly in GUI
-
+
Improvements
Honouring rate limiting messages in TimeMonitor
Updated list of 3rd party dependencies and licenses
-
+
SignServer 3.6.1
-
+
New feature
Added detached signature option to CMSSigner (contributed by Pablo Ruiz García)
-
+
Improvements
Better documentation about how to specify issuer DN for clients and webservice administrators
Issued timestamping certificates for sample soft keystores
-
+
Bug fixes
Fixed KeyStoreCryptoToken to initialize key usage counter when no password is specified in configuration
Fixed a regression when ACCEPTEDEXTENSIONS was empty
@@ -2392,10 +2420,10 @@
Bug fixes
Fixed an issue where issuer DN contains characters that needs escaping
-
+
SignServer 3.6.0
-
+
New features and improvements
Independent worker and crypto token configuration
Querying of database archive from WS and GUI
@@ -2405,16 +2433,16 @@
New features and improvements
Separation between community and enterprise editions
New application: SignServer TimeMonitor (enterprise edition only)
-
+
Bug fixes
Fixed an error when querying the audit log without any conditions
Removed a duplicated invocation in the Admin GUI
-
+
SignServer 3.5.2
-
+
New features and improvements
Support for SHA-2 hash algorithms in PDFSigner
Support for using the worker servlet when running the stress test tool
@@ -2423,7 +2451,7 @@
New features and improvements
System tests are now included in the binary distribution
Apache Santuario (XML Security) library has been updated to version 1.5.7
-
+
Bug fixes
An XML signer performance regression has been fixed by a dependency update
PDF and XAdES signers caused deadlocks under high load when using a local TSA
@@ -2434,10 +2462,10 @@
Bug fixes
-
+
SignServer 3.5.1
-
+
New features and improvements
Support for passing request meta data
Support for configuring number of certificates to include in signature
@@ -2455,7 +2483,7 @@
New features and improvements
Support for setting PKCS#11 attributes without referencing a file
Support for generating keys for JKS soft crypto tokens
-
+
Bug fixes
Fixed AdminGUI smart card login failure on second attempt
Implemented workaround for smart card login error when multiple readers are available for which some does not have tokens present
@@ -2470,10 +2498,10 @@
Bug fixes
Fixed arguments parsing in the renewsigner command and added missing authcode argument
-
+
SignServer 3.5.0
-
+
New features and improvements
Support for JBoss AS 7.1, JBoss EAP 6.1 and GlassFish 3.1.
Support for MariaDB.
@@ -2484,24 +2512,24 @@
New features and improvements
Support for different signature algorithms in XML signers.
Various AdminGUI/remote administration improvements.
-
+
Bug fixes
Empty certificate chain in setproperties call gave error.
-
+
SignServer 3.4.3
-
+
Bug fixes
Regression introduced in 3.4.2: test signatures were not performed as part of the getstatus command or from health check
Security issue in bundled library
-
+
SignServer 3.4.2
-
+
New features and improvements
Uses PKCS11CryptoToken from CESeCore
Support for starting audit log verification from a specified sequence number
@@ -2511,17 +2539,17 @@
New features and improvements
Option to cache PKCS#11 key reference to increase performance
Includes IssuerSerial in the SigningCertificate attribute in time-stamp signer
-
+
Bug fixes
HSM auto activation was not working when signed audit log was used
Key generation was not working with slotListIndex
ClientCLI over web services was not working unless includemodulesinbuild specified
-
+
SignServer 3.4.1
-
+
New features and improvements
Added support for IPv6 and multiple proxies in ListBasedAddressAuthorizer.
Support for specifying the signature algorithm in CMS signer.
@@ -2534,17 +2562,17 @@
New features and improvements
Added health check rate limiter.
Added database setup scripts for PostgreSQL.
-
+
Bug fixes
ContentInfo contained a double encoded octet string in the MS Authenticode time stamp signer.
Unauthorized health check queries incorrectly logged.
-
+
SignServer 3.4.0
This is a major release - in total 27 features, options, bugs and stabilizations have been fixed or added. The most noteworthy changes can be seen below.
-
+
Major changes
Secure logging to database using CESeCore.
Support for querying audit log from CLI, GUI and web services.
@@ -2553,7 +2581,7 @@
Major changes
Database CLI for verifying audit log.
Support for PostgreSQL.
-
+
Bug fixes
Fixed a couple of NPE bugs.
Fixed logging in over webservices using a JKS keystore in the Admin GUI.
@@ -2561,11 +2589,11 @@
Bug fixes
Other minor bugfixes.
-
+
SignServer 3.3.0
This is a major release - in total 57 features, options, bugs and stabilizations have been fixed or added. The most noteworthy changes can be seen below.
-
+
Major changes
New client web services API
MS Authenticode time-stamp signer
@@ -2578,7 +2606,7 @@
Major changes
Upgrade of internal cryptographic library
Many more minor improvements
-
+
Bug fixes
Fixed the Renewal worker which required a trust store password even when a trust store was not used
Fixed an NPE when trying to activate a worker of type Dispatcher
@@ -2589,16 +2617,16 @@
Bug fixes
Fixed Address Authorizers to return HTTP 403 (forbidden) and not HTTP 401 (unauthorized) as before.
-
+
SignServer 3.2.4
-
+
New features and improvements
Installation script contributed by Antoine Louiset
Add test cases for TimeStampSigner with other key algorithms than RSA
StatusPropertiesWorker requires a cryptotoken to be configured
-
+
SignServer 3.2.3
-
+
Major new features and improvements
Support for SignServer without database
Configurable to disable the key usage counter
@@ -2619,7 +2647,7 @@
Major new features and improvements
Down-for-maintenance support in Health check
Support for supplying filename as request metadata
-
+
Bug fixes
Client CLI only supported 10 arguments on Windows
Null value was inserted when removing last wsadmin on Oracle
@@ -2628,29 +2656,29 @@
Bug fixes
Various documentation updates.
-
+
SignServer 3.2.2
-
+
Major new features and improvements
Support for denying timestamp requests unless the time source is considered in sync
Support for dispatching timestamp requests to different timestamp units/signers
Support for accessing workers using the /worker/* URL pattern gives easier filtering with a proxy
-
Signer's status report can now be offered by a worker and not just a timed service
+
Signer's status report can now be offered by a worker and not just a timed service
The log field PROCESS_SUCCESS can now have the value "false" if a request failed
Hostname displayed in title bar of AdminGUI simplifies when managing multiple servers
-
+
Bug fixes
Build failure on W7 X64
Sample code using web services should use HTTPS
URL for documentation only working with JBoss 4.
-
+
SignServer 3.2.1
-
+
Major new features and improvements
Improve servlet error handling
Deploy documentation with application
@@ -2661,7 +2689,7 @@
Major new features and improvements
Support for setting a PDF permissions password
Refuse to certify PDFs already certified and refuse to sign when signing is not allowed
-
+
Bug fixes
Remote EJB worker interface could not be used with ECC with explicit parameters
Warnings printed on STDERR
@@ -2676,11 +2704,11 @@
Bug fixes
JavaDoc failed to build.
-
+
SignServer 3.2.0
This is a major release - in total 49 features, options, bugs and stabilizations have been fixed or added. The most noteworthy changes can be seen below.
-
+
Major new features and improvements
Administration Web Service (WS) interface
Administration GUI desktop application
@@ -2693,22 +2721,22 @@
Major new features and improvements
Improved project structure dividing the modules in sub-projects
Front page listing all demo web pages
-
+
Known Issues
Web services no longer work on JBoss 4 if HTTPS is not used as JBoss 4 rewrites the end point URL in the WSDL file to always start with "https://" (since DSS-327).
-
+
SignServer 3.1.5
This is just a minor maintenance release preparing for the upcoming 3.2 release - in total 7 features, options, bugs and stabilizations have been fixed or added. The most noteworthy changes can be seen below.
-
+
New features and improvements
Support for HTTPS in the SigningAndValidation API
Harden the PDF Signer against PDF signature collisions
Function in the build script for create source-only release archives
"TRUE" if the service only should be run on one of the nodes in the cluster at the time. If it's not set or set to FALSE is the service run simultaneously on all nodes in the cluster. If the node running a singleton service fails will another node sense this and start up the service.
+
"TRUE" if the service only should be run on one of the nodes in the cluster at the time. If it's not set or set to FALSE is the service run simultaneously on all nodes in the cluster. If the node running a singleton service fails will another node sense this and start up the service.
Updated Dependency Affecting Logging Configuration of
The logging framework has been updated from version 1 to the latest version 2. In order to still support the current configuration files for most CLI and standalone applications, those are running with a compatibility bridge and system property log4j1.compatibility=true set. This means that the current configuration (in most cases conf/log4j.properties) should still be working. However, if the user has modified this and added a more advanced configuration it might not be supported in version 2.
-The TimeMonitor application is an example where we had to change to version 2 configuration. For that reason, the TimeMonitor application is not running with the compatibility flag and instead of using the timemonitor-log4j.properties a new timemonitor-log4j2.properties file is used.
+The TimeMonitor application is an example where we had to change to version 2 configuration. For that reason, the TimeMonitor application is not running with the compatibility flag and instead of using the timemonitor-log4j.properties a new timemonitor-log4j2.properties file is used.
Note that any custom modifications in the old timemonitor-log4j.properties file needs to be manually migrated to the new timemonitor-log4j2.properties file in order to be kept.
@@ -1995,7 +1999,7 @@
SignServer 4.1.x to SignServer 4.2.x
No database changes required.
SignServer 4.2.0 Notice
-
The security audit logger (configured in databaseprotection.properties) is now case sensitive when it comes to the key aliases. Make sure your keys are pointed out with the right name. Specifically, if the default sample keystore with alias 'dbstorekey' was used it should now be changed to 'dbStoreKey' as that is the correct name in the keystore.
+
The security audit logger (configured in databaseprotection.properties) is now case sensitive when it comes to the key aliases. Make sure your keys are pointed out with the right name. Specifically, if the default sample keystore with alias 'dbstorekey' was used it should now be changed to 'dbStoreKey' as that is the correct name in the keystore.
@@ -2043,7 +2047,7 @@
For MySQL
SignServer 4.0.0 Notice
-
The way to specify a worker's implementation class name in properties form has changed. Previously it was specified as: GLOB.WORKER4711.CLASSPATH=org.signserver.module.pdfsigner.PDFSigner but should now be specified as a worker property: WORKER4711.IMPLEMENTATION_CLASS=org.signserver.module.pdfsigner.PDFSigner. Exported configurations might have to be adapted. SignServer will try to upgrade existing configurations during startup.
+
The way to specify a worker's implementation class name in properties form has changed. Previously it was specified as: GLOB.WORKER4711.CLASSPATH=org.signserver.module.pdfsigner.PDFSigner but should now be specified as a worker property: WORKER4711.IMPLEMENTATION_CLASS=org.signserver.module.pdfsigner.PDFSigner. Exported configurations might have to be adapted. SignServer will try to upgrade existing configurations during startup.
Each worker configuration should now contain a worker property TYPE, specifying the type of worker such as UNKNOWN, PROCESSABLE, TIMED_SERVICE, SPECIAL or CRYPTO_WORKER. Existing workers will get this worker property populated during the startup.
Previously deprecated crypto token implementations has been removed: SoftCryptoToken, HardCodedCryptoToken, OldPKCS11CryptoToken, and PrimeCardHSMCryptoToken. For SoftCryptoToken and HardCodedCryptoToken, used for demonstration purposes, use KeystoreCryptoToken with the supplied sample configuration. For OldPKCS11CryptoToken, configurations should be upgraded to use PKCS11CryptoToken.
The TimeStampSigner now generates RFC 5816-compliant time stamps with the ESSCertIDv2 attribute. To get the old behavior, specify SHA1 as the certificate digest algorithm, using the new CERTIFICATE_DIGEST_ALGORITHM worker property.
The validation service framework is used to validate certificates from one or more issuers. It can be used to have one central point of performing revokation statuses to simplify the integration of external PKIs within an enterprise.
-
The validation service framework also provides a validation cache that can be used to increase performance for those cases an application does multiple lookups of the same certificate within a short period of time. Out-of-the-Box, there exists a DefaultValidationService that should satisfy most use cases but it's possible to develop a custom ValidationService, if necessary.
+
The validation service framework also provides a validation cache that can be used to increase performance for those cases an application does multiple lookups of the same certificate within a short period of time. Out-of-the-Box, there exists a DefaultValidationService that should satisfy most use cases but it's possible to develop a custom ValidationService, if necessary.
All Validation Services is configured by specifying the org.signserver.validationservice.server.ValidationServiceWorker in the global configuration. Then is the actual ValidationService configured in the worker configuration setting the class path in the property TYPE (not necessary for the DefaultValidationService). The validation service framework is mostly used with X509v3 certificates but other kinds of certificates is supported as well by design.
Another concept in the Validation Service Framework is that the client also can ask the service to check the type of certificate that the certificate might be used for. A certificate type could be IDENTIFICATION or ELECTRONIC SIGNATURE.
SignServer workers are configured to perform certain activities like signing files of a certain type, often with a specific key.
-
+
Common Configuration
Workers are configured by setting properties in the worker configuration. The common configuration options handled by the framework apply to all workers. In addition, there are worker specific properties, handled by the worker implementation. For more information, see Common Configuration.
-
+
Signers
@@ -1748,39 +1752,38 @@
Signers
-
+
Document Validators
Document Validators checks the signature and the certificate(s) in documents. For more information, see SignServer Document Validators.
-
+
Dispatchers
-A SignServer Dispatcher does not perform any processing (i.e. signing) of its own but instead forwards the request to another worker.
+A SignServer Dispatcher does not perform any processing (i.e. signing) of its own but instead forwards the request to another worker.
-Dispatchers forward the request to the first available worker that has a valid certificate (FirstActiveDispatcher), or forward a time-stamp request depending on the requested time-stamp policy (RequestedPolicyDispatcher). For more information, see SignServer Dispatchers.
+Dispatchers forward the request to the first available worker that has a valid certificate (FirstActiveDispatcher), or forward a time-stamp request depending on the requested time-stamp policy (RequestedPolicyDispatcher). For more information, see SignServer Dispatchers.
-A SignServer Timed Service does not accept any input but instead runs at a fixed time interval (like a cron job). This can be useful for setting up an hourly timed service keeping the connection to the Hardware Security Module (HSM) from timing out. For more information, see HSMKeepAliveTimedService. For more information, see SignServer Timed Services.
+A SignServer Timed Service does not accept any input but instead runs at a fixed time interval (like a cron job). This can be useful for setting up an hourly timed service keeping the connection to the Hardware Security Module (HSM) from timing out. For more information, see HSMKeepAliveTimedService. For more information, see SignServer Timed Services.
-
+
Other Workers
-For information on other SignServer workers, see Other Workers. For example, the CryptoWorker that is a holder for configuring the Crypto Token component that is used to access key material. By configuring the Crypto Token in a Crypto Worker other workers can reference this crypto worker and use it for signing etc.
+For information on other SignServer workers, see Other Workers. For example, the CryptoWorker that is a holder for configuring the Crypto Token component that is used to access key material. By configuring the Crypto Token in a Crypto Worker other workers can reference this crypto worker and use it for signing etc.
Ensure to specify a path to a location where SignServer can write files. The default value is empty. If a relative path is used, it is most likely relative to the application server's working directory. The directory should either point to an existing SignServer file database, or be completely empty. If the directory is empty, SignServer will create the initial database structure at startup.
+
Ensure to specify a path to a location where SignServer can write files. The default value is empty. If a relative path is used, it is most likely relative to the application server's working directory. The directory should either point to an existing SignServer file database, or be completely empty. If the directory is empty, SignServer will create the initial database structure at startup.
ENTERPRISE This is a SignServer Enterprise feature.
-
The Signed Request Authorizer requires signed signature requests and that there is a rule matching one of the fields of the client's certificate in the worker's authorization list. Signed signature requests enable signature requests to be signed by a remote client allowing an end-to-end authorization mechanism for deployment scenarios with proxies or similar between the client and the server.
+
The Signed Request Authorizer requires signed signature requests and that there is a rule matching one of the fields of the client's certificate in the worker's authorization list. Signed signature requests enable signature requests to be signed by a remote client allowing an end-to-end authorization mechanism for deployment scenarios with proxies or similar between the client and the server.
Additionally, the authorizer can be configured to also require a TLS client certificate to be present. In that case, any valid client certificate (as verified by the web/application server) will be accepted since the authorization rules for this authorizer only applies to the signed request and not the TLS client certificate. This is different from the Client Certificate Authorizer which instead uses the authorization rules for the TLS client certificate.
@@ -1760,7 +1764,7 @@
Worker Properties
PEM encoded set of trusted certificates to use when verifying the certificate chain of the signed request.
Set the header parameter "typ" to "http://signserver.org/specs/signedrequest/1.0".
-Set the header parameter "x5c" to a list of base64 (
+Set the header parameter "x5c" to a list of base64 (
not base64url) encoded certificates making up the certificate chain with the end entity certificate first.
@@ -1958,7 +1962,7 @@
SignClient Command
-nohttps
-
+
The "-nohttps" is only used here to more easily capture the request with Wireshark/tcpdump.
@@ -2069,7 +2073,7 @@
SOAP Request
</soap:Envelope>
-
+
Data is a reference to a separate part of the HTTP request.
Logged when a worker's configuration was updated by adding and/or removing and/or changing any values.
+
Logged when a worker's configuration was updated by adding and/or removing and/or changing any values.
WORKER_ID: The ID of the worker.
Changes in worker properties are logged with prefixes added/changed/removed followed by a colon and the property name a colon and the property value. Several property changes can occur in one log line (see examples below).
Authorized clients are shown as a property with the name authorized_client.
Detailed information about the state of the TimeMonitor is available in the getstatus output of the TimeMonitorManager:
-
Time monitor: Indicates if the application is detected to be 'Running', 'Disabled', 'Not running?' or 'Unavailabe'. The state is determined by if the manager has seen an update from the TimeMonitor before the status properties are starting to expire.
+
Time monitor: Indicates if the application is detected to be 'Running', 'Disabled', 'Not running?' or 'Unavailabe'. The state is determined by if the manager has seen an update from the TimeMonitor before the status properties are starting to expire.
Last update: The last time the TimeMonitor contacted the manager.
Current time: Current time of the server.
Time state: The last time state from the TimeMonitor.
Report state: The last report state from the TimeMonitor.
Leap state: The last leap state from the TimeMonitor.
-
Configuration: Either 'out of sync' or 'up to date' depending on if the current configuration has been read by the TimeMonitor or not. After changing a property in the TimeMonitorManager it is normal that the configuration is marked as 'out of sync' until the TimeMonitor fetches it.
+
Configuration: Either 'out of sync' or 'up to date' depending on if the current configuration has been read by the TimeMonitor or not. After changing a property in the TimeMonitorManager it is normal that the configuration is marked as 'out of sync' until the TimeMonitor fetches it.
Status properties values: Prints the current value and possibly the expiration time for the TIMESOURCE0_INSYNC and LEAPSECOND status properties.
Timings: Prints the current time values from the TimeMonitor.
Configuration: Prints the configuration values in the manager (not necessarily read by the TimeMonitor yet).
Included certificate chain (currently doesn't include CRLs)
+
Included certificate chain (currently doesn't include CRLs)
Ordering
TSA name
Time-stamp requests are served through a HTTP(S) service at the URL:
@@ -1801,7 +1805,7 @@
Available Properties
ACCEPTEDALGORITHMS
-
A ';' separated string containing accepted algorithms. Can be null if it should not be used. OPTIONAL but strongly recommended. Supported Algorithms are: GOST3411, MD5, SHA1, SHA224, SHA256, SHA384, SHA512, RIPEMD128, RIPEMD160, RIPEMD256.
+
A ';' separated string containing accepted algorithms. Can be null if it should not be used. OPTIONAL but strongly recommended. Supported Algorithms are: GOST3411, MD5, SHA1, SHA224, SHA256, SHA384, SHA512, RIPEMD128, RIPEMD160, RIPEMD256.
@@ -1809,8 +1813,8 @@
Available Properties
ACCEPTEDPOLICIES
-
A ';' separated string containing accepted policies.
-
+
A ';' separated string containing accepted policies.
+
Note that only policies listed in this property are allowed to be requested. If the property does not contain any policies, then no policy can be requested. Requests not including any policy will use the default policy regardless of this property, but requests explicitly requesting the default policy will still not be allowed unless listed in this property. If this property is used, ACCEPTANYPOLICY cannot be set to true. OPTIONAL, recommended.
@@ -1827,7 +1831,7 @@
Available Properties
ACCEPTEDEXTENSIONS
-
A ';' separated string containing accepted extensions, can be null if it should not be used. OPTIONAL.
+
A ';' separated string containing accepted extensions, can be null if it should not be used. OPTIONAL.
@@ -1923,7 +1927,7 @@
Available Properties
INCLUDESTATUSSTRING
-
Specifies if the status string is to be included in the response. Setting this to true triggers a bug in some versions of OpenJDK's jarsigner utility, default is false. OPTIONAL.
+
Specifies if the status string is to be included in the response. Setting this to true triggers a bug in some versions of OpenJDK's jarsigner utility, default is false. OPTIONAL.
@@ -1931,7 +1935,7 @@
Available Properties
INCLUDE_CERTID_ISSUERSERIAL
-
Specifies if the signingCertificate (or signingCertificateV2) attribute's ESSCertID should include the issuer and serial number in addition to the certificate hash. Default is true.
+
Specifies if the signingCertificate (or signingCertificateV2) attribute's ESSCertID should include the issuer and serial number in addition to the certificate hash. Default is true.
@@ -1981,7 +1985,7 @@
Available Properties
Certificate Requirements
Specifying a signer certificate is required as information from that certificate will be used to indicate which signer signed the time-stamp token.
The signer certificate chain contains all certificates included in the token if the client requests the certificates.
-
The signer certificate MUST be included in the configured certificate chain. Other certificates might also be included in the chain (typically intermediate CA certificates). However, if REQUIREVALIDCHAIN=true is specified, only the signer certificate, directly followed by its issuer and then the issuer's issuer and so on, is allowed. All certificates will be verified if there is a certificate coming after it. No check is made that the last certificate is a root certificate as that certificate is usually not included.
+
The signer certificate MUST be included in the configured certificate chain. Other certificates might also be included in the chain (typically intermediate CA certificates). However, if REQUIREVALIDCHAIN=true is specified, only the signer certificate, directly followed by its issuer and then the issuer's issuer and so on, is allowed. All certificates will be verified if there is a certificate coming after it. No check is made that the last certificate is a root certificate as that certificate is usually not included.
A time-stamp signer certificate must have the extended key usage extension present and marked as critical.
The extended key usage extension must contain the timeStamping key purpose ID and only that one.
The following lists algorithm support for the Time Stamp Signer.
-
+
Signature Algorithms
The signer also relies on support for the algorithm in the Crypto Token used, so also review that the desired algorithm is supported by the configured crypto token.
@@ -1761,7 +1765,7 @@
Signature Algorithms
-
+
@@ -1776,7 +1780,7 @@
Signature Algorithms
-
+
@@ -1791,7 +1795,7 @@
Signature Algorithms
-
+
@@ -1806,7 +1810,7 @@
Signature Algorithms
-
+
@@ -1821,7 +1825,7 @@
Signature Algorithms
-
+
@@ -1836,7 +1840,7 @@
Signature Algorithms
-
+
@@ -1851,7 +1855,7 @@
Signature Algorithms
-
+
@@ -1866,7 +1870,7 @@
Signature Algorithms
-
+
@@ -1881,7 +1885,7 @@
Signature Algorithms
-
+
@@ -1896,7 +1900,7 @@
Signature Algorithms
-
+
@@ -1911,7 +1915,7 @@
Signature Algorithms
-
+
@@ -1926,7 +1930,7 @@
Signature Algorithms
-
+
@@ -1941,7 +1945,7 @@
Signature Algorithms
-
+
@@ -1956,7 +1960,7 @@
Signature Algorithms
-
+
@@ -1971,7 +1975,7 @@
Signature Algorithms
-
+
@@ -1986,7 +1990,7 @@
Signature Algorithms
-
+
@@ -2001,7 +2005,7 @@
Signature Algorithms
-
+
@@ -2016,7 +2020,7 @@
Signature Algorithms
-
+
@@ -2029,10 +2033,40 @@
Signature Algorithms
Not applicable to time-stamping.
+
+
+
+
+
+
+
Ed25519
+
+
+
Pure EdDSA with Edwards25519
+
+
+
+
+
+
+
+
+
+
+
+
Ed448
+
+
+
Pure EdDSA with Edwards448
+
+
+
+
+
-
+
Digest Algorithms
Digest algorithms that can be used in time-stamp requests and for which tests have confirmed that the algorithms are supported. Additional algorithms may also work.
There can be a conflict between the JNA implementation in SignServer and the one installed in the system. This can be seen as errors similar to the following:
java.lang.UnsatisfiedLinkError: Can't obtain static newInstance method for class com.sun.jna.Structure
+
java.lang.UnsatisfiedLinkError: Can't obtain static newInstance method for class com.sun.jna.Structure
The solution is to remove JNA from the system (i.e. apt-get remove libjna-java) or to run Java with:
@@ -1865,7 +1869,7 @@
IPv6 dualstack can give permission denied when trying
AdminGUI login using smartcard fails with some cards
-
The card prompts for the PIN but then does not ask for which certificate to login with. Instead, the following error message is shown: Received fatal alert: bad_certificate. The error message indicates that the server did not accept the provided certificate (that is the issuer was not in the server's truststore). However, for certain types of smartcards, the issue is caused by an inability to read a certificate from the card.
+
The card prompts for the PIN but then does not ask for which certificate to login with. Instead, the following error message is shown: Received fatal alert: bad_certificate. The error message indicates that the server did not accept the provided certificate (that is the issuer was not in the server's truststore). However, for certain types of smartcards, the issue is caused by an inability to read a certificate from the card.
-The Xalan library bundled with SignServer is not properly overriding the JBoss-bundled version. You must therefore copy the JAR files from SignServer into JBoss' modules directory and modify the descriptor to use the new version.
+The Xalan library bundled with SignServer is not properly overriding the JBoss-bundled version. You must therefore copy the JAR files from SignServer into JBoss' modules directory and modify the descriptor to use the new version.
The table below lists the Galleon layers used by SignServer.
-
The core-tools layer will include the JBoss and Elytron CLI which comes in handy if the Elytron credential store or the standalone.xml configuration file need to be tweaked later. If you don't need this, exclude the core-tools and management layers and add elytron separately. bean-validation can be excluded as well, but is good to have, at least in staging environments. Picketbox-based web security is required for SignServer to detect authentication using client certificates.
+
The core-tools layer will include the JBoss and Elytron CLI which comes in handy if the Elytron credential store or the standalone.xml configuration file need to be tweaked later. If you don't need this, exclude the core-tools and management layers and add elytron separately. bean-validation can be excluded as well, but is good to have, at least in staging environments. Picketbox-based web security is required for SignServer to detect authentication using client certificates.
@@ -2267,7 +2271,7 @@
MariaDB
-
+
Wait for the reload to complete by checking the server log or the result of :read-attribute(name=server-state) before continuing.
@@ -2284,7 +2288,7 @@
PostgreSQL
-
+
Wait for the reload to complete by checking the server log or the result of :read-attribute(name=server-state) before continuing.
@@ -2303,7 +2307,7 @@
Configure WildFly Remoting
-
+
Wait for the reload to complete by checking the server log or the result of :read-attribute(name=server-state) before continuing.
@@ -2456,7 +2460,7 @@
Remove Existing TLS and HTTP Configuration
-
+
Wait for the reload to complete by checking the server log or the result of :read-attribute(name=server-state) before continuing.
@@ -2532,7 +2536,7 @@
Add HTTP(S) Listeners
-
+
Wait for the reload to complete by checking the server log or the result of :read-attribute(name=server-state) before continuing.
@@ -2622,7 +2626,7 @@
Add HTTP(S) Listeners
-
+
Wait for the reload to complete by checking the server log or the result of :read-attribute(name=server-state) before continuing.
@@ -2774,7 +2778,7 @@
Remove Welcome Content
-
+
Wait for the reload to complete by checking the server log or the result of :read-attribute(name=server-state) before continuing.
@@ -2821,7 +2825,7 @@
Enable HTTP Strict Transport Layer Security
Enable OCSP Revocation Checking
-WildFly can check the validity of client certificates against the OCSP responder defined by the certificate's AIA extension:
+WildFly can check the validity of client certificates against the OCSP responder defined by the certificate's AIA extension:
@@ -2830,7 +2834,7 @@
Enable OCSP Revocation Checking
-
+
Wait for the reload to complete by checking the server log or the result of :read-attribute(name=server-state) before continuing.
@@ -2847,7 +2851,7 @@
Remove the ExampleDS Datasource
-
+
Wait for the reload to complete by checking the server log or the result of :read-attribute(name=server-state) before continuing.
@@ -2893,7 +2897,7 @@
Remove Unused Subsystems and Extensions
-
+
Wait for the reload to complete by checking the server log or the result of :read-attribute(name=server-state) before continuing.
@@ -2909,7 +2913,7 @@
Remove AJP
-
+
Wait for the reload to complete by checking the server log or the result of :read-attribute(name=server-state) before continuing.
@@ -2925,7 +2929,7 @@
Enable AJP Connector
-
+
Wait for the reload to complete by checking the server log or the result of :read-attribute(name=server-state) before continuing.
@@ -2999,7 +3003,7 @@
Disable Management Web Console
-
+
Wait for the reload to complete by checking the server log or the result of :read-attribute(name=server-state) before continuing.
@@ -3087,7 +3091,7 @@
Performance Tuning
-
+
Wait for the reload to complete by checking the server log or the result of :read-attribute(name=server-state) before continuing.
-The Xalan library bundled with SignServer is not properly overriding the JBoss-bundled version. You must therefore copy the JAR files from SignServer into JBoss' modules directory and modify the descriptor to use the new version.
+The Xalan library bundled with SignServer is not properly overriding the JBoss-bundled version. You must therefore copy the JAR files from SignServer into JBoss' modules directory and modify the descriptor to use the new version.
+ 
+ 
This property is not supported with PAdES. 
+ 
+ 
+ 
+ 
+ 