Изменения страницы
Дата последнего изменения указана внизу страницы.
- 5 декабря 2021 г.: Страница реструктурирована: примеры генерации сертификатов и CSR вынесены на отдельную страницу (для уменьшения объёма). Изменена нумерация примеров, добавлен пример с генерацией CSR, обновлён номер версии OpenSSL — до 1.1.1d.
- 4 июня 2021 г.: Добавлено примечание об усилении стойкости ключа в сертификатах X.509 для CNSA. Обновлён список RFC.
- 26 марта 2021 г.: Добавлено примечание об использовании паролей (вместо сертификатов) для аутентификации в TLS, примечание по протоколу ACME, а также о свободных сертификатах, выпуск которых управляется ACME.
- 22 марта 2021 г.: Обновлён список RFC.
- 6 сентября 2021 г.: Иллюстрация и описание возобновления сессии TLS 1.3. В иллюстрацию полного протокола рукопожатия TLS 1.3 добавлено сообщение NewSessionTicket.
- 5 сентября 2021 г.: Иллюстрация и описание полного протокола рукопожатия TLS 1.3.
- 15 августа 2021 г.: Существенные изменения, касающиеся принятия TLS 1.3. Представление расширения “record_size_limit” (TLS 1.2 ). Обновлён список RFC.
- 8 августа 2021 г.: Обновлён список RFC.
- 1 августа 2021 г.: Замена TLS Suite B на CNSA Suite (RFC 8423). Добавлено дополнительное примечание относительно имён в сертификатах X.509. Обновлён список RFC.
- 18 апреля 2021 г.: Дополнительные примечания по наборам шифров. Даны ссылки на реестр IANA и страницу с описанием манипуляций с наборами шифров.
- 11 октября 2021 г.: Добавлено текстовое пояснение в определении Удостоверяющего центра.
- 14 сентября 2021 г.: Добавлено расширение (суффикс) файла .p8. Уточнено, что PKCS v2 поддерживает и закрытый и открытый ключи, v1 — только закрытый. Исправлены примечания по расширению файла .key.
- 2 сентября 2021 г.: В содержании исправлена ссылка на журнал изменений. В некоторых расширениях X.509 V3 для указания значений контекстно-зависимых тегов (TaggedTypes) используются круглые, а не квадратные скобки. Добавлен ASN.1-фрагмент X.509. Добавлено несколько ссылок. Уточнено, что в методе 2 в качестве корневого и серверного используется один и тот же сертификат. Исправлены опечатки.
- 23 августа 2021 г.: Незначительная корректировка и исправление опечаток.
- 12 мая 2021 г.: Добавлено ещё немного увлекательной терминологии, используемой поставщиками сертификатов для описания своих продуктов.
- 20 апреля 2021 г.: При описании элементов X.509 слово “поле” заменено технически корректным термином “атрибут”. Первоначальный замысел использования более общего слова “поле” состоял в том, чтобы уменьшить сложность путём минимизации экзотической терминологии. Но некоторые читатели отметили, что это может привести к путанице, особенно при чтении документации УЦ, в которой упоминаются атрибуты.
- 20 апреля 2021 г.: Добавлены RFC 8062 и 8125.
- 25 января 2021 г.: В таблице соответствия стандартов PKCS#X и RFC обновлена ссылка на RFC для PKCS#5, добавлена информация по PKCS#1 со ссылкой на RFC. В список RFC добавлены RFC 8017 и 8018.
- 16 сентября 2021: Исправлена опечатка в аббревиатуре CRMF. Добавлено примечание о введённом в RFC 7918 “фальстарте”, позволяющем клиенту начинать передачу сообщения сразу после отправки ‘Finished’, не дожидаясь получения ‘Finished’ от сервера. В список RFC добавлены RFC 7918 и 7935.
- 28 июля 2021 г.: Обновлён список RFC. Новый раздел об использовании полей subject и subjectAltName в сертификатах.
- 13 июля 2021 г.: Добавлены недостающие гиперссылки.
- 13 февраля 2021 г.: Обновлён список RFC, исправлены некорректные гиперссылки. Новый раздел об использовании сертификатов в окружении (многопользовательском) хостинг-провайдеров.
- 2 ноября 2021 г.: Добавлена информация по связанным с TLS/SSL/сертификатами именам файлов, форматам и PKCS-контейнерам. Обновлена информация по импорту сертификатов в Chrome, Windows, MSIE и Firefox.
- 28 октября 2021 г.: Обновлён список RFC. Добавлено определение сертификата конечного субъекта.
- 23 октября 2021 г.: Обновлён список RFC. Добавлено примечание по расширению, позволяющему дополнять нулями размер сообщения ClientHello. Добавлено примечание по определённому в RFC 7633 расширению типа ” Pivate Internet”, позволяющее включать в сертификат расширения функционала TLS, что помогает в предотвращении атак. В описание расширений сертификата добавлены OID, чтобы можно было различить стандартные расширения X.509 (из пространства 2.5.29) и расширения “Private Internet” (из пространства 1.3.6.1.5.5.7.1). Текст примеров сокращён (в интересах пользователей с небольшими экранами).
- 29 сентября 2021 г.: Обновлён список RFC. В описание протоколов TLS/SSL добавлено примечание по Extended Master Secret.
- 14 июля 2021 г: Обновлён список RFC. Добавлено примечание об отмене SSL v3.0.
- 10 июля 2021 г: Обновлён список RFC. Добавлено примечание о сертификатах Data Transmission Content Protection (DTCP) и их использовании в протоколе рукопожатия TLS (как определено в RFC 7562).
- 30 мая 2021 г.: Обновлён список RFC. Добавлено примечание об определённом в RFC 7507 “наборе шифров” TLS_FALLBACK_SCSV.
- 15 марта 2021 г.: Обновлён список RFC.
- 5 января 2021 г.: Исправлена битая ссылка на раздел “Цепочки сертификатов X.509”, исправлено неверное указание поля subjectPublicKeyInfo. Исправлена опечатка в описании поля subjectAltName для правильной идентификации использования атрибута dNSName.
- 4 июля 2021 г.: Примечания об упрощённом формате сертификата, определённом в RFC 7250, в описаниях сообщений ClientHello, ServerHello, формата сертификата X.509 и атрибута SubjectPublicKeyInfo. Обновлён список RFC.
- 21 января 2021 г.: Примечание в описании сообщения ClientHello о расширении Server Name Indication (SNI). Обновлён список RFC.
- 22 декабря 2021 г.: Обновлён список RFC.
- 18 декабря 2021 г.: Обновлён список RFC.
- Ноябрь 2021 г.: Страница переделана в HTML5
- Ноябрь 2021 г.: Порядок терминов на странице изменён с SSL/TLS на TLS/SSL для отображения современных тенденций.
- Ноябрь 2021 г.: Обновлён рисунок 2.
- Октябрь 2021 г.: В список RFC добавлены RFC 7027 и 7030. Обновлён текст, касающийся ECC.
Ключевые слова, используемые в элементах begin формата pem
В RFC 7468 определено несколько ключевых слов (или меток), которые могут встречаться в файлах, закодированных в PEM, в элементах —–BEGIN и —–END (но, как это ни удивительно, не определён репозиторий IANA для этих ключевых слов). Кроме того, заголовочный файл pem.
h из пакета OpenSSL (версии 1.0.2d) содержит другие ключевые слова (некоторые из которых явно упразднены в RFC 7468, некоторые могут быть неявно упразднёнными — смотрите примечания ниже). В таблице ниже приведены ключевые слова, собранные из двух источников и снабжённые соответствующими описаниями и комментариями.
Примечание: В закодированных в PEM файлах данные ключевые слова должны присутствовать в обоих элементах BEGIN и END. Для краткости строки —–BEGIN и —-END не показаны, то есть, если в таблице приведено ключевое слово CERTIFICATE, то в PEM-файле оно будет присутствовать дважды: в —–BEGIN CERTIFICATE—– и в —–END CERTIFICATE—–.
| Ключевое слово | Источник | Применение | Примечания |
| CERTIFICATE | RFC 7468 | Содержит один закодированный в DER сертификат X.509v3, как определено в разделе 4 RFC 5280 | В RFC 7468 названы устаревшими ключевые слова X509 CERTIFICATE и X.509 CERTIFICATE |
| X509 CRL | RFC 7468 | Содержит один закодированный в DER список отзыва сертификатов X.509, как определено в разделе 5 RFC 5280 | В RFC 7468 названо устаревшим ключевое слово CRL |
| CERTIFICATE REQUEST | RFC 7468 | Содержит один закодированный в DER запрос сертификата PKCS#10 (он же CSR), как определено в RFC 2986 и дополнено в RFC 5967 | В RFC 7468 названо устаревшим ключевое слово NEW CERTIFICATE REQUEST |
| PKCS7 | RFC 7468 | Содержит закодированный в DER контейнер PKCS#7 (CMS) (в который может быть заключено несколько сертификатов), как определено в RFC 2315 | В RFC 7468 названо устаревшим ключевое слово CERTIFICATE CHAIN и неявно осуждается использование нескольких сертификатов в одной структуре PKCS#7 (в RFC 7468 предлагается заменить PKCS#7 на IETF CMS RFC 5652, смотрите ниже). |
| CMS | RFC 7468 | Содержит закодированный в DER контейнер CMS (в который может быть заключено несколько сертификатов), как определено в RFC 5652 | В основном обратно совместим с описанной выше структурой PKCS#7 |
| PRIVATE KEY | RFC 7468 | Содержит незашифрованный закодированный в DER контейнер PKCS#8 с одним ключом, как определено в разделе 2 RFC 5958 | В RFC 5958 структура PrivateKeyInfo (из RFC 5208) переименована в OneAsymmetricKey, что позволяет помещать в один контейнер как открытый, так и закрытый ключи. Однако, в RFC 7468 этот формат НЕ поддерживается для закодированных в PEM открытых ключей (смотрите описание ключевого слова PUBLIC KEY ниже). Поскольку контейнер PKCS#8 идентифицирует ключевой алгоритм, он неявно делает устаревшим (хотя прямо об этом не говорится) использование ключевых слов RSA PRIVATE KEY, DSA PRIVATE KEY, EC PRIVATE KEY or ANY PRIVATE KEY, DSA PARAMETERS, EC PARAMETERS, DH PARAMETERS (все они могут быть сгенерированы с использованием OpenSSL). |
| ENCRYPTED PRIVATE KEY | RFC 7468 | Содержит зашифрованный закодированный в DER контейнер PKCS#8 с одним ключом, как определено в разделе 3 RFC 5958 | |
| PUBLIC KEY | RFC 7468 | Содержит закодированную в DER структуру SubjectPublicKeyInfo (мини-контейнер) с одним открытым ключом, как определено в разделе 4.1.2.7 RFC 5280 | Структура SubjectPublicKeyInfo описывает ключевой алгоритм и, следовательно, RFC 7468 неявно делает устаревшим (хотя прямо об этом не говорится) использование ключевых слов DSA PUBLIC KEY, RSA PUBLIC KEY и ECSDA PUBLIC KEY (все они могут быть сгенерированы с использованием OpenSSL). |
| ATTRIBUTE CERTIFICATE | RFC 7468 | Содержит закодированный в DER атрибутный сертификат (Attribute certificate), как определено в RFC 5755 | Атрибутные сертификаты представляют собой закодированные в DER сертификаты X.509, НЕ содержащие открытого ключа. В основном они используются в целях авторизации (а не аутентификации). В заголовочном файле pem.h OpenSSL (1.0.2d) нет соответствующего ключевого слова PEM для такого типа сертификата. |
| CERTIFICATE PAIR | pem.h | ?? | Определён в заголовочном файле pem.h OpenSSL, но отсутствует в RFC 7468. В настоящий момент целевой контент не установлен. |
| TRUSTED CERTIFICATE | pem.h | ?? | Определён в заголовочном файле pem.h OpenSSL, но отсутствует в RFC 7468. В настоящий момент целевой контент не установлен, но предположительно это сертификат, где в атрибуте BasicConstraints атрибут cA установлен в TRUE. |
| PKCS #7 SIGNED DATA | pem.h | ?? | Определён в заголовочном файле pem.h OpenSSL, но отсутствует в RFC 7468. В стандарте PKCS#7 разрешено несколько типов контента (‘content types’), один из которых — подписанные данные (эта опция не относится к широко внедрённым). |
| SSL SESSION PARAMETERS | pem.h | ?? | Определён в заголовочном файле pem.h OpenSSL, но отсутствует в RFC 7468. В настоящий момент целевой контент не установлен. |
| X9.42 DH PARAMETERS | pem.h | ?? | Определён в заголовочном файле pem.h OpenSSL, но отсутствует в RFC 7468. В настоящий момент целевой контент не установлен. |
Подключение ssl-сертификата к tomcat
Есть SSL-сертификат, полученный от my-sertif.ru. Точнее, его данные (сам сертификат, корневой сертификат, промежуточный сертификат, запрос на получение сертификата, приватный ключ), в таком формате:
Как мне это дело превратить хотя бы в .crt-сертификат, чтобы потом подключить к томкату? В интернете я нашел только способы создания своего самоподписанного сертификата.
Текст server.xml:
<?xml version="1.0" encoding="UTF-8"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<!-- Note: A "Server" is not itself a "Container", so you may not
define subcomponents such as "Valves" at this level.
Documentation at /docs/config/server.html
-->
<Server port="8005" shutdown="SHUTDOWN">
<Listener className="org.apache.catalina.startup.VersionLoggerListener" />
<!-- Security listener. Documentation at /docs/config/listeners.html
<Listener className="org.apache.catalina.security.SecurityListener" />
-->
<!--APR library loader. Documentation at /docs/apr.html -->
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
<!-- Prevent memory leaks due to use of particular java/javax APIs-->
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
<!-- Global JNDI resources
Documentation at /docs/jndi-resources-howto.html
-->
<GlobalNamingResources>
<!-- Editable user database that can also be used by
UserDatabaseRealm to authenticate users
-->
<Resource name="UserDatabase" auth="Container"
type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>
<!-- A "Service" is a collection of one or more "Connectors" that share
a single "Container" Note: A "Service" is not itself a "Container",
so you may not define subcomponents such as "Valves" at this level.
Documentation at /docs/config/service.html
-->
<Service name="Catalina">
<!--The connectors can use a shared executor, you can define one or more named thread pools-->
<!--
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
maxThreads="150" minSpareThreads="4"/>
-->
<!-- A "Connector" represents an endpoint by which requests are received
and responses are returned. Documentation at :
Java HTTP Connector: /docs/config/http.html
Java AJP Connector: /docs/config/ajp.html
APR (HTTP/AJP) Connector: /docs/apr.html
Define a non-SSL/TLS HTTP/1.1 Connector on port 8080
-->
<Connector port="80" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
<!-- A "Connector" using the shared thread pool-->
<!--
<Connector executor="tomcatThreadPool"
port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
-->
<!-- Define a SSL/TLS HTTP/1.1 Connector on port 8443
This connector uses the NIO implementation. The default
SSLImplementation will depend on the presence of the APR/native
library and the useOpenSSL attribute of the
AprLifecycleListener.
Either JSSE or OpenSSL style configuration may be used regardless of
the SSLImplementation selected. JSSE style configuration is used below.
-->
<!-- Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true">
<SSLHostConfig>
<Certificate certificateKeystoreFile="conf/localhost-rsa.jks"
type="RSA" />
</SSLHostConfig>
</Connector -->
<!-- Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="/root/keystore/defaultkeystore.keystore"
keystorePass="p7JLuFi9nLFBz!"
keyAlias="vk-bots.xyz"/ -->
<!-- Define a SSL/TLS HTTP/1.1 Connector on port 8443 with HTTP/2
This connector uses the APR/native implementation which always uses
OpenSSL for TLS.
Either JSSE or OpenSSL style configuration may be used. OpenSSL style
configuration is used below.
-->
<!-- Это было закомментировано, добавил свои файлы (лежат в / ), результата ноль -->
<Connector port="8443" protocol="org.apache.coyote.http11.Http11AprProtocol"
maxThreads="150" SSLEnabled="true" >
<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />
<SSLHostConfig>
<Certificate certificateKeyFile="mykey.pem"
certificateFile="mycert.crt"
type="RSA" />
</SSLHostConfig>
</Connector>
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
<!-- An Engine represents the entry point (within Catalina) that processes
every request. The Engine implementation for Tomcat stand alone
analyzes the HTTP headers included with the request, and passes them
on to the appropriate Host (virtual host).
Documentation at /docs/config/engine.html -->
<!-- You should set jvmRoute to support load-balancing via AJP ie :
<Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
-->
<Engine name="Catalina" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.MemoryRealm" />
<!--For clustering, please take a look at documentation at:
/docs/cluster-howto.html (simple how to)
/docs/config/cluster.html (reference documentation) -->
<!--
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
-->
<!-- Use the LockOutRealm to prevent attempts to guess user passwords
via a brute-force attack -->
<Realm className="org.apache.catalina.realm.LockOutRealm">
<!-- This Realm uses the UserDatabase configured in the global JNDI
resources under the key "UserDatabase". Any edits
that are performed against this UserDatabase are immediately
available for use by the Realm. -->
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
</Realm>
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
<!-- SingleSignOn valve, share authentication between web applications
Documentation at: /docs/config/valve.html -->
<!--
<Valve className="org.apache.catalina.authenticator.SingleSignOn" />
-->
<!-- Access log processes all example.
Documentation at: /docs/config/valve.html
Note: The pattern used is equivalent to using pattern="common" -->
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="localhost_access_log" suffix=".txt"
pattern="%h %l %u %t "%r" %s %b" />
</Host>
<Host name="www.mydomain.com" appBase="webapps">
<Context
path=""
docBase="mydomain.com"
reloadable="true"
/>
</Host>
<Host name="mydomain.com" appBase="webapps">
<Context
path=""
docBase="mydomain.com"
reloadable="true"
/>
</Host>
</Engine>
</Service>
</Server>
Ошибки из logs/catalina.out (возможно, связанные с этим):
20-Apr-2021 03:14:19.844 INFO [http-nio-80-exec-7] org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request header
Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in method name. HTTP method names must be tokens
at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:408)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:380)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:796)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1368)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
И еще ошибка:
20-Apr-2021 03:12:45.829 SEVERE [main] org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to initialize component [Connector[org.apache.coyote.http11.Http11AprProtocol-8443]]
org.apache.catalina.LifecycleException: The configured protocol [org.apache.coyote.http11.Http11AprProtocol] requires the APR/native library which is not available
at org.apache.catalina.connector.Connector.initInternal(Connector.java:924)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at org.apache.catalina.core.StandardService.initInternal(StandardService.java:530)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at org.apache.catalina.startup.Catalina.load(Catalina.java:606)
at org.apache.catalina.startup.Catalina.load(Catalina.java:629)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
Расширения (суффиксы) файлов
Часто расширение (суффикс) файла не слишком помогает в идентификации его содержимого. Если Вам известен контекст применения файла (что в нём должно быть), то следующая информация может помочь определиться с содержимым:
| Применение | Расширение файла | Закрытый ключ | Формат | Примечания |
| Ключ | .pem | да | PEM | Закодированный в PEM ключ в формате DER в контейнере PKCS#8/RFC 5958, может быть зашифрован или не зашифрован (можно понять по ключевому слову PEM), хотя чаще не зашифрован, поскольку так его используют обычно. Ключевые слова PEM: PRIVATE KEY или ENCRYPTED PRIVATE KEY. Версия 1 (0) поддерживает только закрытые ключи, версия 2 (1) поддерживает использование в PKCS#8 как открытых, так и закрытых ключей. |
| .der | да | DER | Используется редко. Закрытый ключ в чистом виде, закодированный в DER. Без обёртки или идентификатора алгоритма. | |
| .key | да | PEM | Такое расширение используется во многих *nix-системах для обозначения закрытого ключа. Закодированный в PEM ключ в формате DER в контейнере PKCS#8/RFC 5958, может быть зашифрован или не зашифрован, хотя чаще не зашифрован, поскольку так его используют обычно. Ключевые слова PEM: PRIVATE KEY или ENCRYPTED PRIVATE KEY. | |
| .p8 | yes | DER | В RFC 5958 рекомендовано использование этого расширения/суффикса для бинарных (закодированных в DER) файлов PKCS#8. Версия 1 (0) поддерживает только закрытые ключи, версия 2 (1) поддерживает парные открытый и закрытый ключи. Эквивалент меток PEM типов PRIVATE KEY и ENCRYPTED PRIVATE KEY. | |
| Сертификат | .crt | нет | PEM или DER | Обычно в формате PEM (в RFC 7468 предлагается, чтобы это расширение всегда означало PEM-формат). Содержит только сертификат X.509v3. Не контейнер. Такой формат принимают браузеры MSIE, Firefox и Chrome. |
| .cer | нет | PEM или DER | Обычно в формате DER (в RFC 7468 предлагается, чтобы это расширение всегда означало DER-формат). Содержит только сертификат X.509v3. Не контейнер. Такой формат принимают браузеры MSIE, Firefox и Chrome. | |
| .pem | может быть | PEM | Расширение файла не говорит о его содержимом. В файле может быть практически что угодно, от одного ключа до нескольких сертификатов в связке сертификатов УЦ, заключённых в контейнер PKCS#7 (CMS), или даже запрос сертификата PKCS#10. Ключевое слово PEM поможет определиться с содержимым. В некоторых контекстах считается, что файл с таким расширением эквивалентен файлу с расширением .crt. Такой формат принимает только Firefox. | |
| .der | может быть | DER | Расширение файла не говорит о его содержимом. В файле может быть практически что угодно, от одного ключа до нескольких сертификатов в связке сертификатов УЦ, заключённых в контейнер PKCS#7 (CMS), или даже контейнер PKCS#12, или ещё что-то. В некоторых контекстах считается, что файл с таким расширением эквивалентен файлу с расширением .cer. Такой формат принимает только Firefox. | |
| .p12 | может быть | PKCS#12 (RFC 7292) | PKCS#12 (RFC 7292) представляет собой формат закодированного в DER контейнера общего назначения. Может содержать (и, как правило, содержит) один или несколько сертификатов X.509v3 и может содержать (и, как правило, содержит) закодированный в DER закрытый ключ, но может содержать и другие типы данных. Такой формат принимают браузеры MSIE и Chrome. | |
| .pfx | да | RFC 7292 | PKCS#12 (RFC 7292) представляет собой формат закодированного в DER контейнера общего назначения. То же, что и файл с расширением .p12, но обычно используется в системах Microsoft и по соглашению содержит один (или несколько) сертификатов X.509v3, закодированных в DER, и закодированный в DER закрытый ключ. Такой формат принимают браузеры MSIE и Chrome. | |
| .p7b | нет | PKCS#7 (или RFC 5652) | PKCS#7 (или RFC 5652) CMS DER-контейнер, закодированный в PEM. Может содержать один или несколько сертификатов, а также другие объекты. Такой формат принимают браузеры MSIE, Firefox и Chrome. | |
| Разное | .csr | нет | PEM/PKCS#10 | Также может использоваться расширение .pem. Запрос подписи сертификата (CSR). Содержит закодированный в PEM контейнер в формате DER PKCS#10 (RFC 7292), в котором содержатся открытый ключ пользователя, тип алгоритма и атрибуты, которые требуется добавить в сертификат. |
| .crl | нет | PKCS#7 или структура списка сертификатов | Список отзыва сертификатов (CRL) представляет собой закодированную в DER структуру списка сертификатов. Может быть заключена в контейнер PKCS#7 (RFC 2315, или (чаще) просто закодированная в DER структура списка сертификатов, определённая в разделе 5 RFC 5280. Обычно закодирована в PEM. Такой формат принимают браузеры MSIE и Chrome. |
Типы сертификатов x.509 и терминология
При обсуждении вопросов, связанных с сертификатами X.509 (SSL), используется несметное количество терминов. Иногда они применяются последовательно, но в основном — нет, что только добавляет неразберихи. Даже в RFC, посвящённым сертификатам, нет строго определения терминологии, пожалуй, лучше всего с этим обстоят дела в RFC 4210.
Как правило, удостоверяющие центры (УЦ) предлагают несколько типов сертификатов. За исключением сертификатов EV и квалифицированных сертификатов, имеющих точное назначение и определение, все эти типы сертификатов, по большому счёту, — маркетинговая концепция, цель которой — предоставить выбор по цене/функциональности.
Поэтому мы ограничимся лишь поверхностным обзором подобных типов сертификатов, в лучшем случае предоставляя немного технической терминологии. Наконец, не все УЦ одинаковы. Хотя большинство УЦ являются нарочито профессиональными организациями, которые регулярно проверяются или сертифицируются теми или иными национальными организациями, это не всегда так (на сайте УЦ ищите ссылки по аттестации, сертификации и аудиту и смотрите, что там). При покупке сертификата необходимо проявлять бдительность!
Далее предпринята попытка определить наиболее часто используемые термины по удостоверяющим центрам и типам сертификатов в свете того, что было сказано в предыдущем параграфе. Предлагаемые пояснения взяты из технической документации (в основном из RFC, особенно RFC 4210), а также с веб-сайтов удостоверяющих центров.
Удостоверяющий центр (УЦ, он же корневой УЦ, англ. Certificate Authority (CA) a.k.a. root CA): общий термин “удостоверяющий центр” определяется как субъект или организация, подписывающая сертификаты. Корневой УЦ — это УЦ генерирующий корневые сертификаты, имеющие следующие характеристики: атрибуты issuer и subject совпадают; в расширении basicConstraints атрибут cA установлен в TRUE; расширение KeyUsage установлено в keyCertSign (опционально).
Как правило, в цепочке сертификатов сертификат корневого УЦ является сертификатом самого верхнего уровня, однако RFC 4210 определяет, что корневым УЦ может быть любой издатель (issuer), сертификат которого (с расширением basicConstraints, в котором cA установлен в TRUE) получен конечным субъектом (например, браузером) в результате доверенного процесса получения.
Примечание: Мы определили Удостоверяющий центр (УЦ) как эквивалент корневому УЦ. На что нам было справедливо указано, что это не совсем так. Существуют промежуточные и подчинённые удостоверяющие центры (определены ниже), которые не выдают корневые сертификаты.
Мы не стали менять своего определения из-за общепринятого использования данного термина, однако считаем своим долгом предупредить читателей, что термин Удостоверяющий центр (УЦ) является общим, и может быть отнесён, к примеру, и к корневому, и к подчинённому УЦ.
Регистрационный центр (РЦ, он же регистрационный УЦ, англ. Registration Authority (RA) a.k.a. Registration CA): Регистрационный центр (RA) может потребоваться в определенных условиях для обработки специфических характеристик сертификата, например, РЦ может быть делегирован Национальным удостоверяющим центром для специализации на персональных сертификатах, а другой РЦ может специализироваться на сертификатах серверов.
РЦ, если таковые вообще имеются, являются, по сути, неким средством для административного удобства. РЦ могут подписывать сертификаты (как подчинёные УЦ), но обычно, выполнив соответствующие проверки конечного субъекта, передают запрос на подписание корневому УЦ.
Подчинённый центр (подчинённый УЦ, англ. Subordinate Authority a.k.a. Subordinate CA): Общий термин. Любой субъект, подписывающий сертификаты, но не являющийся корневым УЦ. Некоторые подчинённые УЦ – особенно те, которые работают под полным контролем владельца корневого УЦ – могут быть помечены как УЦ (будет присутствовать расширение BasicContraints и cA будет установлено в True).
Промежуточный центр (промежуточный УЦ, англ. Intermediate Authority a.k.a. Intermediate CA): Неточный термин, иногда используется для определения субъекта, создающего промежуточные сертификаты, и, таким образом, охватывает РЦ и подчинённые УЦ.
Кросс-сертификаты (они же сертификаты сцепления или мостовые сертификаты, англ. Cross certificates a.k.a. Chain or Bridge certificate): Кросс-сертификат представляет собой сертификат, в котором субъекты в атрибутах subject и issuer не совпадают, но оба являются удостоверяющими центрами (присутствует расширение BasicConstraints и атрибут cA установлен в True).
Как правило, такие сертификаты используются, когда УЦ изменил некоторые элементы свой политики издания сертифиткатов (новая дата истечения срока действия ключа или новый ключ), либо когда один УЦ был поглощён другим, и сертификаты, изданные поглощённым УЦ, привязываются к новому владельцу, чтобы можно было отказаться от использования ранее выданных корневых сертификатов.
При использовании в данном контексте термин сертификат сцепления указывает на то, что была создана новая привязка, и иногда называется мостовым сертификатом (он привязывается к новому УЦ или выполняет функции моста к нему). Кросс-сертификаты могут быть установлены на сервере (как часть связки сертификатов — смотрите примечание в разделе Протокол TLS, сообщение Certificate), но при использовании для обеспечения обратной совместимости, например, при обработке EV-сертификата несовместимым с EV клиентом, кросс-сертификат устанавливается на клиенте.
Промежуточные сертификаты (они же сертификаты сцепления, англ. Intermediate certificates a.k.a. Chain certificates): Неточный термин, применяемый к любому сертификату, не подписанному корневым УЦ. Промежуточные сертификаты формируют цепочку, в которой на пути от сертификата конечного субъекта до корневого сертификата может быть сколько угодно промежуточных сертификатов.
Промежуточные сертификаты могут быть выпущены подчинёнными УЦ, РЦ или даже напрямую корневым УЦ (хотя технически их следует называть кросс-сертификатами) для различных целей: организации перехода, поглощения или даже просто для дифференциации брендов.
Связка сертификатов (англ. Certificate Bundle): Общий термин, указывающий на то, что в один файл (обычно в формате PEM) объединены несколько сертификатов X.509. Связки сертификатов могут передаваться во время протокола рукопожатия TLS/SSL.
Квалифицированные сертификаты (англ. Qualified certificates): Определённый в RFC 3739 термин “квалифицированные сертификаты” относится к персональным сертификатам (а не к сертификатам серверов или сертификатам конечного субъекта) и ссылается на Директиву Европейского союза об электронной подписи (1999/93/EC), сфокусированную на единообразном определении индивидуума в целях электронной подписи, авторизации или аутентификации.
В частности, данное RFC позволяет содержать в атрибуте subject в порядке очерёдности атрибуты commonName (CN=), givenName (GN=) или pseudonym=, также может присутствовать атрибут subjectDirectoryAttributes, содержащий какие-либо из атрибутов dateOfBirth=, placeOfBirth=, gender=, countryOfCitizenship= и countryOfResidence=.
Наконец, в этом RFC определены два новых расширения biometricInfo и Qualified Certificate statements (qcStatements). Квалифицированный сертификат определяется по наличию расширения qcStatements со значением qcStatement-2.
Большинство правительств конкретных стран добавили для включения в такие сертификаты ряд дополнительных атрибутов. В некоторых случаях на то были реальные причины, в других — просто желание продемонстрировать свои амбиции и сделать невыносимой жизнь тех, кто занимается реализацией стандартов сертификатов.
Неквалифицированные сертификаты (англ. non-Qualified certificates): Вообще, так называют персональные сертификаты, не удовлетворяющие требованиям стандарта квалифицированных сертификатов. Издатели квалифицированных сертификатов также употребляют этот термин по отношению к другим сертификатам с намёком на то, что эти сертификаты более низкого качества.
Сертификат конечного субъекта, он же листовой сертификат (англ. End-Entity Certificate a.k.a Leaf Certificate): Тут всё непросто. Термин “конечный субъект” (в английском варианте могут использоваться как end-entity, так и end entity) изначально определяется в X.
509, а затем в RFC 4949 и RFC 5280. Во всех случаях смысл в том, что сертификат конечного субъекта — это сертификат, в котором для защиты конечного субъекта, описанного в атрибуте CN= атрибутов subject или subjectAltName, используется закрытый ключ (соответствующий открытому ключу, указанному в сертификате конечного субъекта).
С другой стороны, иногда этот термин используется для указания на то, что закрытый ключ (соответствующий открытому ключу, указанному в сертификате конечного субъекта) не используется для подписи сертификатов, то есть, сертификат конечного субъекта не является промежуточным сертификатом, как правило, не является корневым (CA) сертификатом, и, следовательно, не используется в каком-либо процессе проверки подписи.