Hotfix 1.10.12
Release Date: 08/03/2024
Key features
CRL caching and validation
CRL caching and validation is now more robust.
-
use the property server.crl.caching.tolerance to define how long a CRL is considered valid after its fetch date, in milliseconds. The default value is 300000 (5 minutes).
-
use the property server.crl.caching.entries.max to define the maximum number of CRLs that can be per source URL. The default value is 10, and it always keep the most recent CRLs.
-
use the property pdf.validation.crl.tolerance to define how long a CRL is considered valid after its fetchdate, in milliseconds, when validating signatures. The default value is 5000 (5 seconds).
Fixes
-
Fixes some bugs in CRL caching that prevented the CRL response from either being cached or fetched.
-
Fixed a bug when validating an embedded CRL response in a signature, OCSP online is no longer fetched if the embedded CRL response is valid.
-
Fixed a bug when bulk signing and immediately fetching the results, now a proper PENDING status is returned instead of an ERROR.
Security Vulnerabilities
Known vulnerabilities
Dependency | Severity | Vulnerability | Description |
---|---|---|---|
bouncycastle |
MEDIUM |
CVE-2023-33202 |
The iText 7.1.x and 7.2.x suite relies on version 1.67 of the BouncyCastle provider. We have reached out to the vendor, who has assured us that a solution is forthcoming. |
Whitelist vulnerabilities
Dependency | Vulnerability | Description |
---|---|---|
spring-web |
CVE-2016-1000027 |
Spring dismissed this CVE: "The vendor’s position is that untrusted data is not an intended use case. The product’s behavior will not be changed because some users rely on deserialization of trusted data." |
spring-web |
CVE-2024-22243 |
eSign does not use the affected component of Spring. The vulnerability is not applicable to eSign: _"Applications that use UriComponentsBuilder to parse an externally provided URL (e.g. through a query parameter) AND perform validation checks on the host of the parsed URL may be vulnerable to a open redirect https://cwe.mitre.org/data/definitions/601.html attack or to a SSRF attack if the URL is used after passing validation checks." |
jackson-databind |
CVE-2023-35116 |
"The vendor’s perspective is that the product is not intended for use with untrusted input." |
liquibase-core |
CVE-2022-0839 |
This vulnerability does not affect eSign as it does not support external inputs to liquibase libraries |
h2 |
CVE-2021-42392 |
These vulnerabilities only affect H2 databases, which are intended for demo purposes only and should not be used in production environments |
itext-core |
CVE-2022-24198 |
iText dismissed this CVE: "Vendor does not view this as a vulnerability and has not found it to be exploitable." |
itext-* |
CVE-2021-43113 |
This library is included in iText’s bundle but eSign never uses said library. Removed from eSign 1.11.0 and upwards. |
quartz |
CVE-2023-39017 |
Quartz functionalities are not exposed to the outside. |
jose4j |
CVE-2023-31582 |
This vulnerability does not affect eSign as it does not allow the configuration of the number of hashing iterations (which is set at a safe level). |