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).

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).

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.

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.

Person

The user can select the following items on the certificate generation page.

Client

Server

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

http://www.nic.ac/

http://www.nic.ac/pdf/AC-IDN-Policy.pdf

.ar

http://www.nic.ar/

http://www.nic.ar/616.html

.at

http://www.nic.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

http://www.neustarregistry.biz/

http://www.neustarregistry.biz/products/idns

.br

http://registro.br/

http://registro.br/faq/faq6.html

.cat

http://www.domini.cat/

http://www.domini.cat/normativa/en_normativa_registre.html

.ch

http://www.switch.ch/id/

http://www.switch.ch/id/terms/agb.html#anhang1

.cl

http://www.nic.cl/

http://www.nic.cl/CL-IDN-policy.html

.cn

http://www.cnnic.net.cn/

http://www.faqs.org/rfcs/rfc3743.html

JET Guidelines

.cz

https://www.nic.cz/

https://www.nic.cz/page/314/pravidla-a-postupy/

.de

http://www.denic.de/

http://www.denic.de/en/richtlinien.html

.dk

http://www.dk-hostmaster.dk/

http://www.dk-hostmaster.dk/index.html?id=151

.es

https://www.nic.es/

https://www.nic.es/media/2008-12/1228818323935.pdf

.fi

http://www.ficora.fi/

http://www.ficora.fi/en/index/palvelut/fiverkkotunnukset/aakkostenkaytto.html

.gr

https://grweb.ics.forth.gr/english/index.html

https://grweb.ics.forth.gr/english/ENCharacterTable1.jsp

.hu

http://www.domain.hu/domain/

http://www.domain.hu/domain/English/szabalyzat.html

section 2.1.2

.info

http://www.afilias.info/

http://www.afilias.info/register/idn/

.io

http://www.nic.io/

http://www.nic.io/IO-IDN-Policy.pdf

.ir

https://www.nic.ir/

https://www.nic.ir/IDN

.is

http://www.isnic.is/

http://www.isnic.is/english/domain/rules.html

.jp

http://jprs.co.jp/

http://www.iana.org/assignments/idn/jp-japanese.html

.kr

http://domain.nic.or.kr/

http://www.faqs.org/rfcs/rfc3743.html

JET Guidelines

.li

http://www.switch.ch/id/

http://www.switch.ch/id/terms/agb.html#anhang1

managed by .ch registry

.lt

http://www.domreg.lt/public?pg=&sp=&loc=en

http://www.domreg.lt/public?pg=8A7FB6&sp=idn&loc=en

[character list]http://www.domreg.lt/static/doc/public/idn_symbols-en.pdf

.museum

http://about.museum/

http://about.museum/idn/idnpolicy.html

.no

http://www.norid.no/

http://www.norid.no/domeneregistrering/veiviser.en.html

section 4

.org

http://www.pir.org/

http://pir.org/PDFs/ORG-Extended-Characters-22-Jan-07.pdf

.pl

http://www.nask.pl/

http://www.dns.pl/IDN/idn-registration-policy.txt

.pr

https://www.nic.pr/

https://www.nic.pr/idn_rules.asp

.se

http://www.nic-se.se/

http://www.iis.se/en/domaner/internationaliserad-doman-idn/

[character list]http://www.iis.se/docs/teckentabell-03.pdf

.sh

http://www.nic.sh/

http://www.nic.sh/SH-IDN-Policy.pdf

.sk

https://sk-nic.sk/

https://sk-nic.sk/en/documents/rules/

.th

http://www.thnic.or.th/

http://www.iana.org/assignments/idn/th-thai.html

.tm

http://www.nic.tm/

http://www.nic.tm/TM-IDN-Policy.pdf

.tw

http://www.twnic.net.tw/

http://www.faqs.org/rfcs/rfc3743.html

JET Guidelines

.vn

http://www.vnnic.net.vn/

http://www.vnnic.vn/english/5-6-300-2-[2-04-20071115.htm

[character list]http://vietunicode.sourceforge.net/tcvn6909.pdf

Post-quantum cryptography (PQC)

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

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:

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.

The article https://freemindtronic.com/quantum-computing-threats-rsa-aes/ states:

Roots/NewRootsTaskForce/NewCPSConditions (last edited 2025-10-13 14:51:34 by AlesKastner)