Czech |English | Deutsch | ...
Conditions and Rules for issued certificates - 202510
Algorithms
SHA1 (= SHA) usage is deprecated and will only be use only where required by standards as RFCs. Since 2025-08, hash algorithms can be chosen in SHA2 hash function group (SHA-224, SHA-256 /preferred/, SHA-384, SHA-512).
- CAcert currently (2025-10) supports the RSA and the ECC algorithms for X.509 keys.
- X.509 signing uses the SHA256 message digest algorithm. This should be upgraded at least to SHA2.
- OpenPGP Signing uses RSA signing over RSA and DSA keys.
Hash
The SHA1 algorithm will be probably replaced by a more sofisticated successor in the future. In the year 2025, it can be SHA2 hash function group (SHA-224, SHA-256 /preferred/, SHA-384, SHA-512).
- SHA1 - 256, deprecated since 2025-08
- SHA2 - 256, 384, 512
- SHA3 - 256, 384, 512
(source: https://www.keylength.com/en/8/)
Expiration times
On April 14, 2025, the CA/Browser Forum passed a ballot to reduce SSL/TLS certificates to 47 day maximum term by March 15, 2029. (https://en.wikipedia.org/wiki/Certificate_authority#cite_note-44)
Certification type |
Expiration time proposed in present |
Expiration time in the future |
Comment |
Root CA |
20 years |
max. 20 years |
may be reduced down to 5 years |
Subordinate CAs: Person, Client, Server |
5 years |
max. 5 years |
may be reduced down to 2 years |
User's (0-49 APs): Person, Client, Server |
6 months |
200 days (after 20260315), 100 days (after 20270315), 47 days (after 20290315) |
Measure against the Quantum-computer breaking |
User's (50+ APs): Person, Client, Server |
398 days |
200 days (after 20260315), 100 days (after 20270315), 47 days (after 20290315) |
Measure against the Quantum-computer breaking |
The certificate renewal is deprecated
Users are strongly encouraged NOT to renew expired certificates, thus to prefer issuing a new CSR with a new key pair for every certificate they need renew.
This is extremely important for server certificates.
Revoking certificates
Expiration or renewal are not sufficient reasons to revoke a certificate. You shall not revoke a certificate if not required by a good reason as a key compromission.
If you revoke a certificate used for signature, even if it is expired, this means that the key pair was compromised at some time before the revocation. So, if you keep a document for long time (and resign the document including the previous signatures), having one of the certificates revoked could lead to have doubts about the integrity of the document or the signatory.
CSR Minimum requirements
General
These rules are valid for Certificate Signing Requests (CSRs), which are generated by an utility, as OpenSSL, Kleopatra, or XCA. If an user uses the CAcert Web application, the CSR is generated properly.
Key pair: a newly generated pair consisting of a private key and public key. Users must keep their private keys safely.
Only the public key is a part of CSR.
- If the member selects SSO (Single Sign On ID) during submission of CSR: a version of SSO hash type: SHA1 is deprecated now (2025-08), so the SHA2 or SHA3 is now in use, until also obsoletes.
Person
The user can select the following items on the certificate generation page.
The Email address of the user <RFC5322 in 3.4.1>. More Email addresses may be entered as Subject Alternate Names (SANs).
The user's name following <RFC5322 in 3.4>. All strings contained in a CSR and a certificate should be coded as UTF-8.
Note: RFC5280 verification is only mandated for subjectAltName, not for the subject field.
Note for organizations: Even if RFC5280 does not require CN, it is a wip for OAP to state how this is done.- The ability to sign documents or software with the certificate issued.
- The Single Sign-On (SSO) code: a hash of the random number, created with SHA2 hash function group (SHA-224, SHA-256 /preferred/, SHA-384, SHA-512)(2025-09) or following SHA versions.
- The ability to login to the user's account at CAcert.
- The hash algorithm used at certificate signing (issuing). Nowadays SHA-256, SHA-384, or SHA-512 are available.
Client
- The Internet FQDN address of the client: host name of the client computer
Server
- The Internet FQDN address of the server: host name of the server computer
The list of accepted TLD Registrars
This list is expected to be enlarged or modified as necessary. At 2025-8, the TLD list has as many as 1592 items. The most new top-level domains come from the total releasing of making TLD names; now a TLD can be practically anything, created using worldwide letter systems, e.g. .aaa, .bauhaus, .москва, .טעסט, or .電訊盈科.
The following list is then rather historical one. It contains domains of some countries, their registrars and policies.
TLD suffix |
Registrar |
Policy |
Comment |
.ac |
|
||
.ar |
|||
.at |
http://www.nic.at/en/service/legal_information/registration_guidelines/ |
[character list]http://www.nic.at/en/service/technical_information/idn/charset_converter/) |
|
.biz |
|
||
.br |
|
||
.cat |
|
||
.ch |
|
||
.cl |
|
||
.cn |
JET Guidelines |
||
.cz |
|
||
.de |
|
||
.dk |
|
||
.es |
|
||
.fi |
http://www.ficora.fi/en/index/palvelut/fiverkkotunnukset/aakkostenkaytto.html |
|
|
.gr |
|
||
.hu |
section 2.1.2 |
||
.info |
|
||
.io |
|
||
.ir |
|
||
.is |
|
||
.jp |
|
||
.kr |
JET Guidelines |
||
.li |
managed by .ch registry |
||
.lt |
[character list]http://www.domreg.lt/static/doc/public/idn_symbols-en.pdf |
||
.museum |
|
||
.no |
section 4 |
||
.org |
|
||
.pl |
|
||
.pr |
|
||
.se |
[character list]http://www.iis.se/docs/teckentabell-03.pdf |
||
.sh |
|
||
.sk |
|
||
.th |
|
||
.tm |
|
||
.tw |
JET Guidelines |
||
.vn |
[character list]http://vietunicode.sourceforge.net/tcvn6909.pdf |
Post-quantum cryptography (PQC)
- (Cryptographic algorithms resistant against Quantum-computer break)
- (Research: AI)
Post-quantum cryptography (PQC) is concerned with the design of cryptographic algorithms that can withstand cryptanalytically relevant quantum computers. The goal is to replace the asymptotic methods commonly used today based on factorization or discrete logarithm, which are vulnerable due to Shore's algorithm.
Main classes of post-quantum algorithms
- Lattice-based
- Code-based
- Multivariate-based
- Hash-based
- Isogeny-based
These categories are based on various mathematical problems for which there are no efficient quantum solutions known by the time of standard cryptanalytic attacks.
NIST Standardization and the Main Candidates
NIST (National Institute of Standards and Technology) conducted a competition to standardize the first PQC algorithms. The winners include:
- CRYSTALS-Kyber (KEM)
- CRYSTALS-Dilithium (Digital Signature)
- FALCON (digital signature)
- SPHINCS+ (hash-based digital signature)
These algorithms were selected for their security level and performance in different application scenarios.
Quantum Key Distribution (QKD)
In addition to the purely mathematical approaches of PQC, there is Quantum Key Distribution (QKD) technology that uses the physical principles of quantum mechanics to provide secure transmission of encryption keys. Ideally, QKD is combined with PQC for maximum data protection against both present and future quantum attacks.
Next steps and related topics
- Research on quantum-resistant "hybrid" protocols combining classical and post-quantum elements.
- Monitoring developments in quantum computing and cryptanalytic research.
- Involvement in standardisation initiatives (IETF, ETSI) for the introduction of PQC in Internet protocols.
The article https://freemindtronic.com/quantum-computing-threats-rsa-aes/ states:
- Key takeaways:
RSA-2048 & AES-256 remain safe against quantum attacks through at least 2035.
- Grover’s algorithm reduces AES-256 strength to 2¹²⁸ operations—still infeasible.
- Shor’s algorithm would require ~20 million stable qubits to break RSA-2048.
- HQC draft selected in March 2025, final standard expected by 2027.
- Segmented key encryption by Jacques Gascuel offers immediate post-quantum defense.
