Czech |English | Deutsch | ...
Conditions and Rules for issued certificates - 202506
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.
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.
- more...?
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 |
Some cryptographic algorithms resist against Quantum-computer break
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.
Reference to the SHA1 hash algorithm
The SHA1 algorithm will be probably replaced by a more sofisticated successor in the future.
More
...?