Помимо перехода на «сверхкороткие» сертификаты, который быстро приближается, есть ещё несколько интересных новых моментов, связанных с TLS-сертификатами для веба. В феврале 2025 года Let’s Encrypt выпустили демонстрационный «шестидневный» сертификат от одного из своих основных промежуточных УЦ (E6). На примере этого сертификата можно увидеть челый ряд новшеств и неочевидных моментов, которые разобраны в статье. Для упрощения изложения, в качестве иллюстрации при разборе я использую не байты сертификата, а текстовую распечатку значений полей, полученную при помощи утилиты x509 из OpenSSL.
Итак, мы рассмотрим простую текстовую распечатку. Вообще, исходный TLS-сертификат состоит из блоков двоичных данных, объединённых структурой, которая задаётся спецификациями. Типы блоков, их длина — определяются внутренними идентификаторами. Собирательно, схема называется ASN.1, а исходный формат именно сертификатов — это X.509, который очень давно придумали для целей документальной электросвязи (для телеграфа).
Низкоуровневая интерпретация значений отдельных блоков сертификата выполняется в соответствии с их ASN.1-типами и расположением в заданной структуре, а высокоуровневая интерпретация — в соответствии с «ожиданиями» интерпретирующей программы и по так называемым OID («идентификаторы объектов»), которые входят в состав сертификата на правах обычных блоков.
Текстовая распечатка ниже — это нестрогое человекопонятное представление содержательных данных, которые утилита просмотра смогла извлечь из сертификата и успешно интерпретировать. Тем не менее, данный текстовый формат очень удобен для первоначального знакомства со структурами TLS-сертификатов.
Все комментарии — дальше по тексту, а тут, для справки, полная распечатка без комментариев и сам сертификат в Base64 (внутри PEM).
Скрытый текст
Certificate: Data: Version: 3 (0x2) Serial Number: 03:b0:b0:15:c1:a4:e2:64:16:11:73:1a:71:1b:71:1d:e0:ef Signature Algorithm: ecdsa-with-SHA384 Issuer: C = US, O = Let's Encrypt, CN = E6 Validity Not Before: Feb 19 17:30:01 2025 GMT Not After : Feb 26 09:30:00 2025 GMT Subject: Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:28:48:8b:6d:d9:5d:5a:a1:c2:39:77:1a:ca:47: c8:8b:7e:69:b4:2a:25:6f:3a:18:b0:28:1c:b3:bb: 69:0b:78:2e:c2:d0:17:5f:02:0b:70:74:80:9d:92: e1:21:01:7a:24:85:72:ea:e8:33:59:66:09:a1:e5: 3e:1f:95:5c:19 ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Authority Key Identifier: keyid:93:27:46:98:03:A9:51:68:8E:98:D6:C4:42:48:DB:23:BF:58:94:D2 Authority Information Access: OCSP - URI:http://e6.o.lencr.org CA Issuers - URI:http://e6.i.lencr.org/ X509v3 Subject Alternative Name: critical DNS:helloworld.letsencrypt.org X509v3 Certificate Policies: Policy: 2.23.140.1.2.1 CT Precertificate SCTs: Signed Certificate Timestamp: Version : v1 (0x0) Log ID : CC:FB:0F:6A:85:71:09:65:FE:95:9B:53:CE:E9:B2:7C: 22:E9:85:5C:0D:97:8D:B6:A9:7E:54:C0:FE:4C:0D:B0 Timestamp : Feb 19 18:28:32.078 2025 GMT Extensions: none Signature : ecdsa-with-SHA256 30:45:02:20:53:5D:E7:54:DF:48:D8:89:AC:EF:B6:F7: 8B:78:F4:2E:40:35:CE:28:0B:B8:13:53:37:FB:C6:79: 4D:96:12:AC:02:21:00:C2:2E:61:7E:20:BD:4A:C2:8B: C6:54:D0:D2:C7:2D:53:18:4B:99:D6:21:E3:4A:FA:10: 25:90:4B:FC:96:C3:60 Signed Certificate Timestamp: Version : v1 (0x0) Log ID : E0:92:B3:FC:0C:1D:C8:E7:68:36:1F:DE:61:B9:96:4D: 0A:52:78:19:8A:72:D6:72:C4:B0:4D:A5:6D:6F:54:04 Timestamp : Feb 19 18:28:32.147 2025 GMT Extensions: none Signature : ecdsa-with-SHA256 30:46:02:21:00:AC:D8:DB:99:21:42:25:A0:E6:87:D6: DF:5E:5C:32:9B:F1:B8:E8:58:44:81:3E:C2:B8:8B:60: 71:32:F1:08:B3:02:21:00:E3:0D:69:03:72:AF:56:24: CE:B7:0D:53:3D:79:A8:65:74:A1:52:E0:E4:12:4D:FA: 29:16:C5:73:9D:71:11:C5 Signature Algorithm: ecdsa-with-SHA384 30:65:02:30:30:0d:ab:2e:c6:d3:d0:08:c3:35:dc:77:b4:8d: 97:bb:85:c2:10:be:c6:57:dd:ba:fa:75:3d:e1:03:1d:cf:c5: 03:d2:b7:99:16:24:19:7b:8a:b7:33:5d:3a:1e:f0:70:02:31: 00:b8:c4:30:39:81:42:2c:17:6c:1e:38:ee:81:a4:69:90:1e: d2:ba:b1:03:71:2d:35:5e:70:8f:4a:1b:78:e6:e5:ba:3f:cd: 81:4b:15:10:6f:4e:aa:20:48:a2:08:05:47 -----BEGIN CERTIFICATE----- MIIDSzCCAtGgAwIBAgISA7CwFcGk4mQWEXMacRtxHeDvMAoGCCqGSM49BAMDMDIx CzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQDEwJF NjAeFw0yNTAyMTkxNzMwMDFaFw0yNTAyMjYwOTMwMDBaMAAwWTATBgcqhkjOPQIB BggqhkjOPQMBBwNCAAQoSItt2V1aocI5dxrKR8iLfmm0KiVvOhiwKByzu2kLeC7C 0BdfAgtwdICdkuEhAXokhXLq6DNZZgmh5T4flVwZo4IB9zCCAfMwDgYDVR0PAQH/ BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwHwYDVR0j BBgwFoAUkydGmAOpUWiOmNbEQkjbI79YlNIwVQYIKwYBBQUHAQEESTBHMCEGCCsG AQUFBzABhhVodHRwOi8vZTYuby5sZW5jci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6 Ly9lNi5pLmxlbmNyLm9yZy8wKAYDVR0RAQH/BB4wHIIaaGVsbG93b3JsZC5sZXRz ZW5jcnlwdC5vcmcwEwYDVR0gBAwwCjAIBgZngQwBAgEwggEFBgorBgEEAdZ5AgQC BIH2BIHzAPEAdgDM+w9qhXEJZf6Vm1PO6bJ8IumFXA2XjbapflTA/kwNsAAAAZUf d/zOAAAEAwBHMEUCIFNd51TfSNiJrO+294t49C5ANc4oC7gTUzf7xnlNlhKsAiEA wi5hfiC9SsKLxlTQ0sctUxhLmdYh40r6ECWQS/yWw2AAdwDgkrP8DB3I52g2H95h uZZNClJ4GYpy1nLEsE2lbW9UBAAAAZUfd/0TAAAEAwBIMEYCIQCs2NuZIUIloOaH 1t9eXDKb8bjoWESBPsK4i2BxMvEIswIhAOMNaQNyr1YkzrcNUz15qGV0oVLg5BJN +ikWxXOdcRHFMAoGCCqGSM49BAMDA2gAMGUCMDANqy7G09AIwzXcd7SNl7uFwhC+ xlfduvp1PeEDHc/FA9K3mRYkGXuKtzNdOh7wcAIxALjEMDmBQiwXbB447oGkaZAe 0rqxA3EtNV5wj0obeObluj/NgUsVEG9OqiBIoggFRw== -----END CERTIFICATE-----Итак, разбор.
Certificate: Data: Version: 3 (0x2) Serial Number: 03:b0:b0:15:c1:a4:e2:64:16:11:73:1a:71:1b:71:1d:e0:efВерсию формата пропускаем — это просто 0x02. Смотрим на серийный номер. И уже здесь начинаются неочевидные моменты. Этот серийный номер начинается с 0x03. Это не простое совпадение. Почему? Потому что согласно спецификации серийный номер должен быть положительным целым числом. Хитрость в том, что в ASN.1 и в сертификатах для записи этого поля исторически используется представление со знаком, так что первый слева бит — это бит знака, и он должен иметь значение 0. При этом актуальные рекомендации требуют, чтобы серийные номера сертификатов имели достаточно большую разрядность и были «непредсказуемыми». Поэтому сейчас серийные номера генерируют (псевдо)случайным образом. И вот чтобы случайно или псевдослучайно не попасть в отрицательную область, левый полубайт (ниббл) принудительно делают равным нулю. Иначе, значение байта больше 0x80 приведет к тому, что запись серийного номера окажется отрицательным числом. Вообще никак не влияет на практическую обработку серийных номеров, но нарушает требования к формату. «Знаковые ошибки» в серийном номере уже приводили к массовому отзыву дефектных сертификатов. Впрочем, механизмы отзыва тоже уходят в прошлое.
Много энтропии в серийном номере ввели для того, чтобы затруднить атаки, основанные на предсказании состава ещё не выпущенного сертификата. Значения прочих полей нетрудно предсказать, и эффект когда-то давно был актуален для MD5, так как позволяет предвычислить коллизии хеш-функций.
Вообще, первый байт (слева) серийного номера правильно целиком использовать для каких-то внутренних целей, как это делают все грамотные и прозорливые УЦ — Let’s Encrypt и не только. Например, 0x03 может обозначать поколение ключей, версию ПО или ещё что-то такое.
Signature Algorithm: ecdsa-with-SHA384«Историческое» поле в сертификате, повторяющее указание на тип подписи. (Подпись ставит УЦ, подпись указана в конце сертификата.)
Issuer: C = US, O = Let's Encrypt, CN = E6Выпущен УЦ E6 от Let’s Encrypt, находящегося в юрисдикции США (US). Полное значение Issuer должно совпадать с Subject в вышестоящем сертификате, который содержит открытый ключ подписывающего УЦ.
Validity Not Before: Feb 19 17:30:01 2025 GMT Not After : Feb 26 09:30:00 2025 GMTТе самые шесть дней валидности (плюс 16 часов «на погрешности»).
Subject:Легко было незаметить и пропустить. Subject. Но он пустой. Это одно из новшеств. Браузеры уже довольно давно требуют наличия имени домена в поле SAN, а не в Subject, CN из которого для DV-сертификатов просто игнорируют (тут есть совсем уж технические детали, касающиеся сортировки сертификатов при валидации в Firefox, но мы их тут не рассматриваем). Теперь Subject вообще будет пустым, как в этом сертификате, а имя домена мы встретим ниже.
Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:28:48:8b:6d:d9:5d:5a:a1:c2:39:77:1a:ca:47: c8:8b:7e:69:b4:2a:25:6f:3a:18:b0:28:1c:b3:bb: 69:0b:78:2e:c2:d0:17:5f:02:0b:70:74:80:9d:92: e1:21:01:7a:24:85:72:ea:e8:33:59:66:09:a1:e5: 3e:1f:95:5c:19 ASN1 OID: prime256v1 NIST CURVE: P-256Это открытый ключ ECDSA на кривой P-256 — самый ходовой набор, самая популярная кривая, одобрено NIST и многими другими профильными организациями.
X509v3 extensions: X509v3 Key Usage: critical Digital SignatureОткрытый ключ разрешается использовать только для цифровой подписи. Это то, что требуется в TLS. Прочие варианты, типа передачи ключа и зашифрования — больше не должны использоваться. Например, RSA-шифрование для передачи сеансового секрета в TLS — прямо запрещено спецификацией TLS 1.3.
X509v3 Extended Key Usage: TLS Web Server AuthenticationРасширенные флаги для ключа: только использование для аутентификации сервера. В этом поле повсеместно можно встретить ещё и разрешение для аутентификации клиента. Например, те сертификаты, которые Let’s Encrypt выпускает сейчас, содержат здесь TLS Web Server Authentication, TLS Web Client Authentication.
X509v3 Basic Constraints: critical CA:FALSEЭто не ключ УЦ в сертификате (не должен подписывать другие сертификаты).
X509v3 Authority Key Identifier: keyid:93:27:46:98:03:A9:51:68:8E:98:D6:C4:42:48:DB:23:BF:58:94:D2Идентификатор ключа — это просто подсказка, облегчающая поиск ключа УЦ, пропускаем.
Authority Information Access: OCSP - URI:http://e6.o.lencr.org CA Issuers - URI:http://e6.i.lencr.org/А этот блок, в принципе, должен отражать важное новшество, но в демонстрационном сертификате новшества пока что не видно. Это адреса двух точек получения информации УЦ. Точка первая (OCSP) — URI респондера OCSP, то есть, респондера, позволяющего получить сведения о статусе сертификата (отозван или не отозван).
Что тут интересно? Во-первых, дни OCSP в Let’s Encrypt сочтены: УЦ отказывается от поддержки этого протокола, уже к августу 2025 года. Надо сказать, правильно делает, что отказывается: отзыв сертификатов и отслеживание их статуса вообще представляют одну из самых больших технических проблем для УЦ, а OCSP так вообще чрезвычайно неудобный, уязвимый, плохо масштабируемый сервис (но зато там простой протокол, да). Однако в этом сертификате OCSP указан. Почему? Потому что демонстрационный сертификат нужно было как-то отозвать, а статус отзыва — опубликовать штатным способом.
Во-вторых, современная версия рекомендаций CA/B-форума позволяет в «сверхкоротких» сертификатах вообще не указывать никаких сведений о способах проверки статуса сертификата. Раньше для всех TLS-сертификатов был один обязательный способ, — списки отзыва (CRL), — и один опциональный способ — OCSP-респондер. В современной версии рекомендаций введено понятие «сверхкоротких» сертификатов (со сроком валидности не более десяти дней) и для «сверхкоротких» можно не указывать никаких способов проверки того, отозван сертификат или нет.
Мотивация всё та же: отзыв всё равно в вебе фактически не работает, а сертификат со сроком действия в несколько дней быстро «протухает» автоматически. Выгода: экономия на сопровождении сервисов с информацией о статусе сертификатов — и это очень большая экономия для УЦ. Кроме того, если потребуется «отозвать» сразу миллионы сертификатов, то не нужно будет ничего делать — не придётся раздувать списки отзыва потоком серйиных номеров, а потоком записей о статусах — раздувать базы OSCP-сервисов. Если потребуется исключить миллионы доменов из перечня тех, кому разрешено выпускать сертификаты, то тоже достаточно будет перекрыть выпуск новых сертификатов — уже выпущенные быстро перестанут быть действительными, всё так же, без раздутия баз и списков. Удобно.
X509v3 Subject Alternative Name: critical DNS:helloworld.letsencrypt.orgЭто DNS-имя, для которого валиден данный сертификат: helloworld.letsencrypt.org.
X509v3 Certificate Policies: Policy: 2.23.140.1.2.1Политика, согласно которой сертификат был выпущен. Политики представляют собой своды правил, которым УЦ следовал при генерировании данного сертификата и при проверке права управления сетевым ресурсом, для которого сертификат валиден. Идентификаторы политик влияют на процесс валидации в браузерах. Например, именно политикой отличаются EV-сертификаты, а каких-то технических особенностей сертификата там нет. Но, всё же, это больше административный момент.
CT Precertificate SCTs:Начинается блок меток SCT (подписанная метка времени — Signed Certificate Timestamp), которые выдают логи Certificate Transparency (далее — CT-логи). Метка содержит цифровую подпись (от ключа CT-лога) и привязана к составу сертификата. Наличие метки здесь означает, что соответствующий пресертификат был предъявлен оператору лога. Обратите внимание, что именно пресертификат — это отражено и в названии поля. То есть, пресертификат — это как бы такой же сертификат, но выпущенный раньше и имеющий в своём составе специальное расширение CT Poison, которое, будучи отмечено как критическое, должно препятствовать успешной валидации. Это «костыль» Certificate Transparency версии 1.0, позволяющий победить проблему курицы и яйца, получив SCT-метку для сертификата, выпуск которого требует наличия SCT-меток.
Signed Certificate Timestamp: Version : v1 (0x0) Log ID : CC:FB:0F:6A:85:71:09:65:FE:95:9B:53:CE:E9:B2:7C: 22:E9:85:5C:0D:97:8D:B6:A9:7E:54:C0:FE:4C:0D:B0 Timestamp : Feb 19 18:28:32.078 2025 GMTПервая SCT-метка получена 19 февраля в 18:28:32, с «копейками» миллисекунд. Это таймстемп, формируемый CT-логом, который должен обозначать время, когда лог получил пресертификат. Log ID — это отпечаток файла открытого ключа лога. Это SCT от лога Cloudflare «Nimbus2025».
Однако обратите внимание на значение таймстемпа: 18:28:32, но сам сертификат начинает действовать в 17:30:01 (см. интервал валидности выше), почти на час раньше. Как так? Интервал валидности должен совпадать в пресертификате и в сертификате, иначе не сойдётся подпись в SCT-метке. Получается, пресертификат был выпущен за час до того, как УЦ предъявил его логу? Нет, конечно же. Это рядовой «бэкдейтинг», но скромный — время выпуска сертификата поставлено на час (примерно) раньше фактического, чтобы, как заявлено, компенсировать проблемы с неточными часами. Действительно, сертификаты Let’s Encrypt выпускаются автоматом и сразу должны публиковаться на веб-сервере. Соответственно, если клиентские часы отстают, то свежий сертификат может оказаться по локальным часам «в будущем» (какая-то теория относительности, не находите?), то есть, ещё не действует. 60 минут выбраны потому, что в этот интервал, как считается, укладывается подавляющее большинство практических отклонений часов. Вот поэтому Let’s Encrypt пишет в сертификаты время на час раньше.
Extensions: none Signature : ecdsa-with-SHA256 30:45:02:20:53:5D:E7:54:DF:48:D8:89:AC:EF:B6:F7: 8B:78:F4:2E:40:35:CE:28:0B:B8:13:53:37:FB:C6:79: 4D:96:12:AC:02:21:00:C2:2E:61:7E:20:BD:4A:C2:8B: C6:54:D0:D2:C7:2D:53:18:4B:99:D6:21:E3:4A:FA:10: 25:90:4B:FC:96:C3:60Подпись из состава SCT-метки (ECDSA на кривой P-256).
Signed Certificate Timestamp: Version : v1 (0x0) Log ID : E0:92:B3:FC:0C:1D:C8:E7:68:36:1F:DE:61:B9:96:4D: 0A:52:78:19:8A:72:D6:72:C4:B0:4D:A5:6D:6F:54:04 Timestamp : Feb 19 18:28:32.147 2025 GMT Extensions: none Signature : ecdsa-with-SHA256 30:46:02:21:00:AC:D8:DB:99:21:42:25:A0:E6:87:D6: DF:5E:5C:32:9B:F1:B8:E8:58:44:81:3E:C2:B8:8B:60: 71:32:F1:08:B3:02:21:00:E3:0D:69:03:72:AF:56:24: CE:B7:0D:53:3D:79:A8:65:74:A1:52:E0:E4:12:4D:FA: 29:16:C5:73:9D:71:11:C5 Вторая SCT-метка. CT-лог Sectigo «Sabre2025h1». CT-логи ведут сами УЦ. Это может показаться странным, но как-то так сложилось.
Signature Algorithm: ecdsa-with-SHA384 30:65:02:30:30:0d:ab:2e:c6:d3:d0:08:c3:35:dc:77:b4:8d: 97:bb:85:c2:10:be:c6:57:dd:ba:fa:75:3d:e1:03:1d:cf:c5: 03:d2:b7:99:16:24:19:7b:8a:b7:33:5d:3a:1e:f0:70:02:31: 00:b8:c4:30:39:81:42:2c:17:6c:1e:38:ee:81:a4:69:90:1e: d2:ba:b1:03:71:2d:35:5e:70:8f:4a:1b:78:e6:e5:ba:3f:cd: 81:4b:15:10:6f:4e:aa:20:48:a2:08:05:47 Завершается текстовый дамп сертификата значением подписи. Это просто ECDSA на кривой P-384, которую использует Let’s Encrypt для УЦ E6. Подпись вычисляется для всего состава сертификата, который приведён выше. Корректное значение подписи — это то, что и делает сертификат полезным.
ссылка на оригинал статьи https://habr.com/ru/articles/901312/
Добавить комментарий