Phasing out Addtrust External CA Root certificate

Что такое ca root chain

Далее – найдём сертификат владельца нашего сертификата (Issuer: CN=EssentialSSL CA):

# keytool -printcert -file EssentialSSLCA_2.crt | grep CN
Owner: CN=EssentialSSL CA, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
Issuer: CN=COMODO Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB

Теперь – посмотрим сертификат для COMODO Certification Authority:

Почему возникает ошибка?

Во время подключения, TLS-сервер отправляет клиенту сертификат. Браузер выстраивает цепочку сертификатов – от сертификата на сервере до корневого сертификата – для этого сервер отправляет несколько промежуточных сертификатов, включая свой собственный.

Современные браузеры могут построить эту цепочку самостоятельно, однако устаревшие браузеры и клиенты, которые все еще используют OpenSSL 1.0.x или GnuTLS, увидят сообщение о небезопасном соединении.

Addtrust external ca root certificate – adbd987a34b426f7fac42654ef03bde024cb541a

Chain of trust

Every SSL certificate is issued under a root certificate. Root certificates are self-signed certificates controlled by a CA like Sectigo and are included in the trusted root store of a browser. This is important for the support of the SSL certificates: when more browsers trust a root Certificate, the SSL certificates issued under this root certificate will be more widely trusted.

Between a root certificate and an SSL certificate one or more intermediate certificates are present. Together they provide a complete chain (‘chain of trust’) to the root certificate. By using intermediate certificates, the root certificate itself doesn’t need to sign a certificate.

This way the root certificate can stay off-line, which makes it less vulnerable for abuse. Intermediate certificates can be considered as signage pointing to the root certificate. An SSL certificate is signed by an intermediate and the intermediate by the root certificate. Not installing them can in some cases lead to errors when visiting the page on which the certificate is active.

Client reports certificate not issued by trusted certificate authority

To address:

Cross-signing

To build up a good compatibility of a new root takes time. Therefore Sectigo SSL certificates are cross-signed under two different root certificates, the earlier discussed Addtrust External CA root with a validity till May 2020 en the relatively new – and because of this less widely supported – Comodo RSA Certification Authority root certificate valid until May 2038.

Impact

Thousands of web sites / services / APIs which present certificates that were issued by the vendor may have experienced trouble negotiating incoming secure connections from their clients. Exact issues, if any, depended on a mix of server configuration, client version, and client configuration.

A client validating any of those certificates had access to 3 “paths” to do so successfully. One of those paths (A) became invalid after the above certificates expired:

The expired certificates

The following certificates expired on May 30 10:48:38 2020 GMT:

Thumbprints

Each certificate has his own, unique thumbprint. From the previously discussed certificates these are:

Addtrust External CA Root root certificate:

02faf3e291435468607857694df5e45b68851868

Comodo RSA Certification Authority intermediate certificate:

f5ad0bcc1ad56cd150725b1c866c30ad92ef21b0

Comodo RSA Certification Authority root certificate:

afe5d244a8d1194230ff479fe2f897bbcd7a8cb4

This enables you to check with certainty which certificate is present on the server.

Will my sectigo (comodo) certificate still be trusted?

Because of the compatibility and widespread browser support of the Addtrust External CA root certificate we still offer this root certificate. When it expires and a client already has the Comodo RSA Certification authority root present in it’s trusted root, it will be used automatically.

Because of this, installing the old root won’t lead to any problems from May 30, 2020. You will see that newer clients familiar with the Comodo RSA Certification authority root, already use it. Nowadays certificates get issued with a maximum validity of two years.

Some visitors are still using legacy devices. Because of this we advice to use the old chain. From May 30, 2020, legacy devices that don’t have the new root in the trusted root, unfortunately will give an error.

Note: A Windows Server automatically offers the shortest chain. It is possible to disable the new root certificate until the Addtrust External CA root certificate is expired.

The list below shows all minimum versions of software that will have no problems. All browsers and operating systems that are older than the versions below, do not contain de new root certificates and might give errors.

Apple:

• macOS Sierra 10.12.1 Public Beta 2
• iOS 10
• Windows XP
• Windows Phone

Mozilla:

Google:

Oracle:

Opera:

• Browser releases after december 2021

360 Browser:

• SE 10.1.1550.0 and Extreme browser 11.0.2031.0

With this test environment you can check if your setup will cause problems. For this you need to adjust the clock to a date after June 1, 2020.

Заказ ssl-сертификата у certificate authority (ca)

Переходим на страницу оформления заказа на сертификат, кликаем на Большую Зелёную КнопкуFree Trial SSL, потом на такую же ещё раз – и попадаем на страницу оформления заказа.

Тут в поле 1. вставляем текст из нашего csr-файла:

Выбираем тип подтверждения владения доменом, в данном случае – через почту в этом домене:

Заполняем оставшиеся поля:

Соглашаемся – ставим галочку, и кликаем Большую Синюю Кнопку:

Открываем подсвеченное красным:

В почте находим письмо от Comodo с номером заказа:

В письме находим код:

Вводим его в поле на сайте, кликаем Next:

Всё, ждём. Сейчас письмо с сертификатами пришло буквально через 5 минут, в прошлый раз – только на следующий день.

Так выглядит само письмо:

Нам важно в нём следующее:

Attached to this email, you should find a .zip file containing:
Root CA Certificate - AddTrustExternalCARoot.crt
Intermediate CA Certificate - UTNAddTrustSGCCA.crt
Intermediate CA Certificate - ComodoUTNSGCCA.crt
Intermediate CA Certificate - EssentialSSLCA_2.crt
Your Free SSL Certificate - akira_setevoy_kiev_ua.crt

Это цепочка из Root, Intermediate и самого сертификата для сервера.

Истёк срок действия корневого сертификата addtrust external ca root | leaderssl

Как исправить ошибку?

Есть два способа исправления ошибки корневого сертификата AddTrust. 

Первый способ – перевыпустить и заново установить ваш сертификат:

Если SSL сертификат имеет тип проверки «Домен»: в этом случае рекомендуется перевыпустить сертификат, чтобы он автоматически подписывался обновленной цепочкой. Выдача произойдет в течение 15 минут (опция Reissue в вашем личном кабинете).

Если SSL сертификат имеет тип проверки «Организация» или расширенный тип проверки: когда сертификат будет перевыпущен, вам потребуется установит его на свой сервер. Если вы хотите, чтобы мы установили новый сертификат на ваш сервер, то обратитесь к нашей службе поддержки; если вы хотите выполнить установку самостоятельно, тогда используйте руководство по установке SSL, соответствующее вашему веб-серверу.

Второй способ – обновить цепочку сертификатов (CA-bundle) для установленного SSL-сертификата: 

Как проверить мой сертификат?

Для начала нужно проверить, использует ли ваш сайт просроченный корневой сертификат цепочки:

Решение со стороны клиента

Внимание! Тут далее по тексту размещаются сертификаты безопасности и предложения их импортировать в систему. Это референс! Не надо бездумно импортировать их в trust store и делать доверенными. Мы в Интернете и тут нельзя никому доверять (даже Хабру, sad but true)!

Если просто импортировать промежуточные сертификаты, как правило, достаточно безопасно (не делая их вручную “доверенными”, они наследуют доверие сами и без вас), то импортировать самоподписные руты надо строго включая мозг и сверяя отпечатки сертификатов с эталонными значениями, указанными на сайтах вендоров сертификатов. Praemonitus, praemunitus.

Как правило, если владелец сервера с проблемным сертификатом уже заменил цепочку, то на стороне клиента делать ничего не нужно, так как недостающий промежуточный сертификат имеет кросс-подпись от достаточно старого CA, который с большей долей вероятности уже был заботливо предустановлен в trust store даже сильно legacy-системы при царе Горохе. И всё должно работать.

Решение со стороны сервера

Стоит продублировать решение ещё и тут. Ниже располагаются два набора цепочек для сертификатов DV Sectigo (не Comodo!), одна для привычных RSA сертификатов, другая для менее привычных ECC (ECDSA) сертификатов (мы используем две цепочки достаточно давно).

Цепочка для сертификатов, основанных на алгоритме ключа RSA. Сравните со своей цепочкой и обратите внимание, что заменился только нижний сертификат, а верхний остался прежним. Я их отличаю в бытовых условиях по последним трём символам блоков base64 не считая символа “равно” (в данном случае En8= и 1 V):

Создание private key сервера и .csr – запроса на получение сертификата

Для начала – создаём сертификат, который мы будем использовать в нашем приложении:

# keytool -genkey -keysize 2048 -keyalg RSA -alias akiraCom -keystore /home/setevoy/.ssh/akiraCom.jks
Enter keystore password:
Re-enter new password:
What is your first and last name?
[Unknown]:  akira.setevoy.kiev.ua
What is the name of your organizational unit?
[Unknown]:
What is the name of your organization?
[Unknown]:
What is the name of your City or Locality?
[Unknown]:  Kiev
What is the name of your State or Province?
[Unknown]:
What is the two-letter country code for this unit?
[Unknown]:  UA
Is CN=akira.setevoy.kiev.ua, OU=Unknown, O=Unknown, L=Kiev, ST=Unknown, C=UA correct?
[no]:  yes

Enter key password for <akiraCom>
(RETURN if same as keystore password):

Если после заполнения получаете подобную ошибку – попробуйте отписаться в support Comodo – вопрос решили в течении пары часов:

> An account already exists for “kiev.ua”

Потребуется регистрация – но она простая.

Продолжим. Сейчас нам необходимо создать .csr-файл – Запрос на получение сертификата (Certificate signing request). По сути он просто содержит в себе ту информацию, которую вы указали во время генерации сертификата (Private Key) сервера.

# keytool -certreq -alias akiraCom -file /home/setevoy/.ssh/akiraCom.csr -keystore /home/setevoy/.ssh/akiraCom.jks
Enter keystore password:

# ls -l | grep akiraCom
-rw-r--r--  1 root     setevoy    1023 Jan 23 14:12 akiraCom.csr
-rw-r--r--  1 root     setevoy    2222 Jan 23 14:11 akiraCom.jks

# cat akiraCom.csr
-----BEGIN NEW CERTIFICATE REQUEST-----
MIICtzCCAZ8CAQAwcjELMAkGA1UEBhMCVUExEDAOBgNVBAgTB1Vua25vd24xDTALBgNVBAcTBEtp
...
HA8oFRfKN/pZXPLpvTJKwcgI7eD/HTXEcEidFQZ6G044OKbyZ2Tr0ytxt1w3Cqq 3pbZTawROPmR
to8Rbw AfgOE0xNQ4n4C
-----END NEW CERTIFICATE REQUEST-----

Установка root, intermediate и подписанного сертификата сервера

Распаковываем архив в удобное место:

# unzip akira_setevoy_kiev_ua.zip
Archive:  akira_setevoy_kiev_ua.zip
extracting: AddTrustExternalCARoot.crt
extracting: UTNAddTrustSGCCA.crt
extracting: ComodoUTNSGCCA.crt
extracting: EssentialSSLCA_2.crt
extracting: akira_setevoy_kiev_ua.crt

# ls -l
total 64
-rwxr-xr-x  1 root  setevoy  1521 May 30  2000 AddTrustExternalCARoot.crt
-rwxr-xr-x  1 root  setevoy  1679 Dec  1  2006 ComodoUTNSGCCA.crt
-rwxr-xr-x  1 root  setevoy  1797 Dec  1  2006 EssentialSSLCA_2.crt
-rwxr-xr-x  1 root  setevoy  1671 Jun  7  2005 UTNAddTrustSGCCA.crt
-rwxr-xr-x  1 root  setevoy  1846 Jan 23 00:00 akira_setevoy_kiev_ua.crt
-rw-------  1 root  setevoy  9134 Jan 23 18:37 akira_setevoy_kiev_ua.zip

Теперь – разберёмся, что из этих сертификатов – Root, какие – Intermediate, т.е. “промежуточные”.

С помощью утилиты keytool посмотрим информацию о сертификате:

# keytool -printcert -file akira_setevoy_kiev_ua.crt | grep CN
Owner: CN=akira.setevoy.kiev.ua, OU=Free SSL, OU=Domain Control Validated
Issuer: CN=EssentialSSL CA, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB

Owner – владелец, т.е. мы;Issuer – “эмитент”, т.е. – поставщик данного сертифката.

Что бы сработал SSL Handshake – “рукопожатие”, запрос должен пройти цепочку (“chain“) от сертификата сервера – до Root-сертификата Центра Сертификации (CA – Certificate authority).

В некоторых случаях, как в этом примере – между нашим сертифкатом и сертификатом нашего CA есть Intermediate, промежуточные, CA, и их сертификаты должны быть установлены в то же хранилище.

Просмотреть эту цепочку можно по полям Owner/Issuer сертификата. В примере выше мы видим, что и эмитент – EssentialSSL CA, а владелец – akira.setevoy.kiev.ua.