Skip to content

Certification Hierarchy

mihkeltammsalu edited this page Mar 7, 2024 · 40 revisions

Changes in certification hierarchy 2024

What will change in CA hierarchy?

SK’s certification authority (CA) chain named EECCRCA (Estonian Certification Centre Root CA) has been in use since 2010 and will be valid until end of 2030. This trusted CA chain will be replaced with new root certificate, together with new intermediate certificates. The new CA chain is already in use for SKs Timestamping service. See figure 1 for current setup and figure 2 for new CA chains. Figure 1: Current CA chain   Figure 1: Current CA chain

Figure 2: New CA chain Figure 2: New CA chain

Why are all these changes necessary overall?

This change can be considered as regular transition in PKI (Public Key infrastructure) ecosystem. Of course, there are several reasons for it in detail, like:

  • EECCRCA root CA together with intermediate CA’s will be expiring 2030. So therefore, to ensure the sustainability for certificate management of associated services, it is inevitable to take new CA chain into use.
  • Cryptography – EECCRCA, as it is made in 2010, uses still SHA1 algorithm, what shouldn’t be used. Although its intermediate CA’s use already more secure algorithms. So new ROOT G1 certification chain uses even more secure and mature cryptographic algorithms. Both ECC (Elliptic Curve Cryptography) and RSA will be used. Moving to new PKI hierarchy and using more secure key lengths adds more security and helps to preserve the integrity.

Why is there two new root certificates and double intermediate certificates?

True, there are a pair of each certificate for root and for intermediate certificates. One is based on ECC cryptography and the another on is using RSA. The idea behind it, is to create and have “hot standby” backup CA hierarchy, what could be taken into use, if for example, some flaws are detected in one cryptographic algorithm. By having both already implemented and trusted in the PKI ecosystem, makes it easy to take another into use in shortest timeframe possible. Now important is to note, that certificates will be issued from one issuing CA at a time - ECC will be the primary issuing CA! RSA is backup and does not actively issue end-entity certificates.

CA’s are distinguishable by looking CA common name in the subject field, following “E” or “R” in the end. For example:

  • SK ID Solutions EID-Q 2021E – this is based on ECC, 521 length key;
  • SK ID Solutions EID-Q 2021R – this is based on RSA, 4094 length key.

The same logic goes for all other root and intermediate CA’s.

Of course, opening the certificate in detail, there are more specific hints, what algorithm is being used. See below comparison on ROOT G1E and ROOT G1R certificate:
Figure 3: Comparison of Root G1E and G1R certificates

Figure 3: Comparison of Root G1E and G1R certificates

Where can I find new root and intermediate certificates?

New root certificates and intermediate certificates can be found/downloaded from SK’s repository here https://www.skidsolutions.eu/resources/certificates/.

Here are direct certificate download links for production environment:

ROOT certificates:

Intermediate CA certificates:

Intermediate CAs not yet created:

  • SK ID Solutions EID-Q 2024E – available during Q2-Q3
  • SK ID Solutions EID-Q 2024R - available during Q2-Q3

Also TEST environment CA certificates are available in same repository link, under Test certificates tab.

What about new certificates being in Estonian TL (Trusted List)?

Intermediate certificates SK ID Solutions EID-Q 2021E, SK ID Solutions EID-Q 2021R, SK ID Solutions ORG 2021E, and SK ID Solutions ORG 2021R are already added in the EE Trusted List (EU Trusted List).

Root certificate is not being added in TL.

Test certificates are added into test Trusted List https://open-eid.github.io/test-TL/.

Trusted List is managed by RIA (Estonian Information System Authority).

When will the change come into effect?

To disperse the potential impact on services, we have decided to gradually take new intermediate CAs into use during 2024. For all intermediate CA’s SK will send notification directly to customers base, and for others information will be updated here under this Github space, when exact dates are put in place.

In grand plan, it is currently predictable quarterly:

Figure: PKI timeline

Figure 4: PKI timeline

The first one in the row is ORG 2021 which is used for issuing organisation certificates (legal persons) like eSeal, Authentication and Encryption certificates.

ORG 2021 will be taken into use with the following deadlines:

  • test environment: 12.03.2024
  • production environment: 09.04.2024

Figure 4: KLASS3-SK 2016 CA switch to ORG 2021E CA

Figure 4: KLASS3-SK 2016 CA switch to ORG 2021E CA

Will something change also in end-entity certificates?

Slightly, considered as low impact changes. End-entity certificates for organisation (eSeal, Auth, Crypto), personal certificates for Smart-ID and Mobile-ID service:

  • Signature algorithm – sha256ECDSA will be used in ECC CA issued certificates and sha256RSA will be used in RSA CA chain (secondary).
  • Issuer – as certificates are issued by new CAs, then logically the Issuer subject DN (distinguished name) is set according to corresponding CA.

What validation methods will be available for new CAs?

Both OCSP (Online Certificate Status Protocol) and CRL (Certificate Revocation List), will be available.

It is important to note that not all CRL’s and OCSP URL-s are yet published. Will be done timely before CA is taken into use for test or production. More information here: https://github.com/SK-EID/ocsp/wiki#sk-ocsp

Who will be affected by this change?

All e-services, applications and information systems using directly or indirectly certificates issued by, including but not limited to:

  • X-road users (security servers) – X-road ecosystem uses eSeal and Authentication certificates. New issuing CA ORG2021E will be configured in X-road ecosystem by RIA (Estonian Information System Authority). Further changes regard X-road will be done/guided by RIA.
  • validation & signing solution providers
  • solutions which use custom trust store for certificates instead of EU Trusted List

What are the key aspects to consider in order to keep everything working and be ready on time?

  1. Make sure that new CA certificates in your information system are supported/trusted.
  2. When available, get test certificate or a token with certificate issued by new CA and test with your application/service.
  3. Most Estonian specific libraries (for example digidoc4j or libdigidocpp) use validation logic built on top of EU Trusted List. Therefore, no changes are foreseen if using these.

NB! solutions which use custom trust store for certificates instead of EU Trusted List may need to be configured.

In general, following the timeline mentioned in the section When will the change come into effect? it is wise to add support of all issuing CAs at once (if needed), to be ready to support the changes ahead!

Does ID-card PKI chain (EE-GovCA 2018) changes also?

No, current root certificate named EE-GovCA2018 together with ESTEID2018 intermediate CA, which is used for issuing digital certificates for ID1 type of documents (ID-cards, digi-ID, etc.), stays as it is. No changes expected there!

What will happen with current PKI hierarchy (EE Certification Centre Root CA), will it be terminated?

The certificates issued under EECCRCA hierarchy, followed by the intermediate CAs, will be served until expiry of the last certificate issued by it.

Clone this wiki locally