Let's Encrypt — это центр сертификации, который предоставляет бесплатные сертификаты в полностью автоматизированном процессе. Эти сертификаты выдаются по протоколу ACME. За последние два года в Интернете широко использовалась технология Let’s Encrypt — более 50% веб-сертификатов SSL / TLS теперь выдает Let’s Encrypt.
В этом посте описывается, как выдавать сертификаты Let's Encrypt для внутренних серверов.
Хотя и существует множество инструментов для автоматического обновления сертификатов для общедоступных веб-серверов (certbot, simp_le, я писал о том, как это сделать), трудно найти какую-либо полезную информацию о том, как выдавать сертификаты для внутренних серверов, не подключенных к Интернету, и / или устройства с Let's Encrypt.
В Datto мы выдали сертификат на каждую из наших 90 000+ устройств BCDR, использующих именно этот механизм.
Содержание
Hello Hacker News, впервые на главной странице HN! Для меня это большая честь! Я ответил на все вопросы в разделе комментариев.
Если вы ищете реализацию этой идеи, вам может быть интересен localtls. Я сам не тестировал, но похоже, что он делает то же самое, что я здесь описываю.
Вот немного подробностей об этом процессе:
Участники этого процесса:
В этом примере предположим, что мы пытаемся выпустить сертификат для устройства с идентификатором xi8qz и локальным IP-адресом 10.1.1.4. С точки зрения этого устройства необходимо сделать два запроса:
2.1. Предварительные требования: назначение домена для каждой машины (шаги 1-3)
Как упоминалось выше, нам нужно дать каждому устройству правильное доменное имя, чтобы иметь возможность подтвердить право собственности на Let's Encrypt, поэтому нам нужно купить домен (здесь: example.com) и делегировать его NS-записи нашему серверу DDNS:
$ dig +short NS example.com
ddns1.mycompany.com.
Вдобавок к этому нам нужна возможность динамически добавлять и удалять записи из него (через какой-то API). Я ранее писал о том, как развернуть собственный DDNS-сервер, если вам интересно.
После того, как все это настроено, нам нужно убедиться, что запись A машины обновляется при изменении ее IP-адреса. Для нашей внутренней машины давайте назначим xi8qz.example.com в качестве домена. Если все работает правильно, вы сможете разрешить этот домен по его IP-адресу, используя обычный DNS-запрос:
$ dig +short xi8qz.example.com
10.1.1.4
2.2. Запрос сертификата (шаги 4-14)
Предполагая, что теперь вы полностью контролируете зону DNS для example.com и можете быстро редактировать ее динамически, у вас все готово для фактической выдачи сертификатов для вашего локального домена устройства через Let's Encrypt.
В нашем примере устройства оно будет регулярно проверять, действителен ли существующий сертификат (шаг 4). Если сертификата нет или срок действия существующего скоро истечет, устройство сгенерирует пару ключей и запрос на подпись сертификата (CSR), используя назначенное ему имя хоста (здесь: xi8qz.example.com) в качестве CN, и оно отправит этот CSR на управляющий сервер (шаг 5).
После авторизации запроса (важный шаг, не показанный на схеме!), Управляющий сервер запрашивает DNS-запрос для данного домена из ACME API через вызов Pre-Authorization / new-authz API (шаг 6). ACME API отвечает запросом DNS (шаг 7). Если все идет хорошо, это выглядит примерно так:
{
"identifier": {
"type": "dns",
"value": "xi8qz.example.com"
},
"status": "pending",
"expires": "2018-04-15T21:26:29Z",
"challenges": [
{
"type": "dns-01",
"status": "pending",
"uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/VtjihR4X8nLAj4MDwI...",
"token": "aLptEKAeUOajkiGrx-kkbjUX4b1MC..."
},
// ...
],
// ...
}
Используя этот ответ, управляющий сервер должен установить запись DNS TXT на _acme-challenge.xi8qz.example.com (шаг 8) и уведомить ACME API о том, что ответ на запрос был размещен (шаг 9).
После того, как ответ на запрос был проверен с помощью Let's Encrypt (шаг 10-11), сертификат можно, наконец, запросить с помощью CSR (шаг 12-13).
После того, как Let's Encrypt ответит сертификатом, вы увидите на проводе что-то вроде этого:
-----BEGIN CERTIFICATE-----
MIIGEjCCBPqgAwIBAgISAyk2izMz7OXSqHeZhg+rUR5uMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
...
Если декодировать с помощью openssl, мы увидим, что это настоящая сделка:
$ openssl x509 -in www.crt -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
03:29:36:8b:33:33:ec:e5:d2:a8:77:99:86:0f:ab:51:1e:6e
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Validity
Not Before: Jul 18 23:37:35 2018 GMT
Not After : Oct 16 23:37:35 2018 GMT
Subject: CN=xi8qz.example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:be:69:df:28:04:9c:2b:e9:94:72:c3:de:a6:fd:
a4:38:93:be:43:a7:81:8b:dc:9a:be:19:0d:c0:d1:
...
Этот сертификат затем возвращается в машину (шаг 14). После перезапуска веб-сервера устройства / сервера к его веб-интерфейсу можно будет получить доступ через HTTPS в браузере или из командной строки:
$ curl -v https://xi8qz.example.com/login
* Trying 10.1.1.4...
* TCP_NODELAY set
* Connected to xi8qz.example.com (10.1.1.4) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=xi8qz.example.com
* start date: Jul 18 23:37:35 2018 GMT
* expire date: Oct 16 23:37:35 2018 GMT
* subjectAltName: host "xi8qz.example.com" matched cert's "xi8qz.example.com"
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
> GET /login HTTP/1.1
> Host: xi8qz.example.com
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Sun, 05 Aug 2018 17:38:49 GMT
< Server: Apache/2.4.18 (Ubuntu)
...
Сделав это для всех внутренних серверов, мы можем обеспечить безопасную связь в нашей внутренней ИТ-инфраструктуре без необходимости развертывания настраиваемого сертификата CA или необходимости платить за сертификаты.
Интересные Github проекты по этой теме:
https://github.com/RealTimeLogic/SharkTrust
https://github.com/joohoi/acme-dns
https://github.com/skoerfgen/CertLE
https://github.com/Corollarium/localtls
Источник статьи: https://habr.com/ru/post/568378/
В этом посте описывается, как выдавать сертификаты Let's Encrypt для внутренних серверов.
Хотя и существует множество инструментов для автоматического обновления сертификатов для общедоступных веб-серверов (certbot, simp_le, я писал о том, как это сделать), трудно найти какую-либо полезную информацию о том, как выдавать сертификаты для внутренних серверов, не подключенных к Интернету, и / или устройства с Let's Encrypt.
В Datto мы выдали сертификат на каждую из наших 90 000+ устройств BCDR, использующих именно этот механизм.
Содержание
- Как это работает?
- Пример: внутренний сервер 10.1.1.4, он же. xi8qz.example.com
2.1. Предварительные требования: назначение домена для каждой машины (шаги 1-3)
2.2. Запрос сертификата (шаги 4-14) - Рекомендации по развертыванию: ограничения скорости Let's Encrypt.
Hello Hacker News, впервые на главной странице HN! Для меня это большая честь! Я ответил на все вопросы в разделе комментариев.
Если вы ищете реализацию этой идеи, вам может быть интересен localtls. Я сам не тестировал, но похоже, что он делает то же самое, что я здесь описываю.
- Как это работает?
Чтобы выпустить сертификат с помощью Let's Encrypt, вы должны доказать, что вы либо являетесь владельцем веб-сайта, для которого хотите выпустить сертификат, либо владеете доменом, на котором он работает. Обычно автоматизированные инструменты, такие как certbot, используют HTTP-запрос для подтверждения права собственности на сайт с использованием .well-known каталога. Хотя это прекрасно работает, если сайт подключен к Интернету (и Let's Encrypt может проверять файлы HTTP-запросов с помощью простого HTTP-запроса), он не работает, если ваш сервер работает на 10.1.1.4 или на любом другом внутреннем адресе.
DNS решает эту проблему, позволяя подтвердить право собственности на домен с помощью TXT-записи DNS _acme-challenge.example.com. Let's Encrypt проверит, что запись соответствует ожидаемому, и выдаст ваш сертификат, если все сложится.
Итак, действительно волшебными ингредиентами для выдачи сертификатов для внутренних компьютеров, не подключенных к Интернету, являются:- Выделенная зона DNS для всех ваших внутренних устройств, например xi8qz.example.com и динамический DNS-сервер для управления этой зоной (здесь: example.com)
- Клиент ACME, способный использовать DNS-запрос Let's Encrypt для подтверждения права собственности на домен.
- Пример: внутренний сервер 10.1.1.4, он же. xi8qz.example.com
На следующей диаграмме показано, как мы реализовали интеграцию Let's Encrypt для наших устройств резервного копирования Datto. Каждое устройство (читайте: внутренний сервер) находится за NAT и имеет собственный локальный IP-адрес.
Общий подход прост: устройство регулярно обращается к нашему серверу управления, чтобы обеспечить доступ к нему через его собственный поддомен. Если его локальный IP-адрес изменяется, он запускает обновление своего собственного поддомена. Кроме того, он регулярно проверяет, действителен ли сертификат, и запрашивает обновление, если он устарел.
Вот немного подробностей об этом процессе:
Участники этого процесса:
- Внутренний сервер (ip: 10.1.1.4, id: xi8qz)
- Сервер управления
- DDNS-сервер (владеет example.com)
- Let's Encrypt ACME
| Порядок прохождения запроса на сертификат |
|---|
| 1. Проверка, если локальный IP-адрес изменился |
| 2. Обновление записи DNS для xi8qz.example.com с 10.1.1.4. |
| 3. Установка запись A для xi8qz.example.com на 10.1.1.4. |
| xi8qz.example.com теперь резолвится до 10.1.1.4 |
| 4. Если необходимо продление, генерация CSR для xi8qz.example.com |
| 5. Запрос продления с CSR для xi8qz.example.com |
| 6. Запрос DNS-запрос для xi8qz.example.com (new-aithz) |
| 7. URL запроса DNS и токен |
| 8. Установка записи TXT для acme challenge.xi8qz.example.com. |
| 9. Уведомление о размещении вызова (вызов) |
| 10. Подтверждение вызов |
| 11. Убедждение, что вызов был подтвержден (повтор до успешного завершения). |
| 12. Запрос сертификат с CSR (new-cert) |
| 13. Сертификат (и цепочка) |
| 14. Сертификат (и цепочка) |
В этом примере предположим, что мы пытаемся выпустить сертификат для устройства с идентификатором xi8qz и локальным IP-адресом 10.1.1.4. С точки зрения этого устройства необходимо сделать два запроса:
- Шаги 1-3: Во-первых, ему необходимо установить / обновить свой собственный DNS-домен (здесь: xi8qz.example.com). Этот домен позже будет использоваться в сертификате как общее имя (CN). Кроме того, необходимо убедиться, что эта запись обновляется каждый раз при изменении IP-адреса сервера.
- Шаги 4-14: необходимо регулярно проверять, нужно ли обновлять локальный сертификат, и запрашивать обновление, если пришло время. Очевидно, что если сертификата нет, его нужно «обновить».
Давайте теперь рассмотрим эти шаги более подробно.
2.1. Предварительные требования: назначение домена для каждой машины (шаги 1-3)
Как упоминалось выше, нам нужно дать каждому устройству правильное доменное имя, чтобы иметь возможность подтвердить право собственности на Let's Encrypt, поэтому нам нужно купить домен (здесь: example.com) и делегировать его NS-записи нашему серверу DDNS:
$ dig +short NS example.com
ddns1.mycompany.com.
Вдобавок к этому нам нужна возможность динамически добавлять и удалять записи из него (через какой-то API). Я ранее писал о том, как развернуть собственный DDNS-сервер, если вам интересно.
После того, как все это настроено, нам нужно убедиться, что запись A машины обновляется при изменении ее IP-адреса. Для нашей внутренней машины давайте назначим xi8qz.example.com в качестве домена. Если все работает правильно, вы сможете разрешить этот домен по его IP-адресу, используя обычный DNS-запрос:
$ dig +short xi8qz.example.com
10.1.1.4
2.2. Запрос сертификата (шаги 4-14)
Предполагая, что теперь вы полностью контролируете зону DNS для example.com и можете быстро редактировать ее динамически, у вас все готово для фактической выдачи сертификатов для вашего локального домена устройства через Let's Encrypt.
В нашем примере устройства оно будет регулярно проверять, действителен ли существующий сертификат (шаг 4). Если сертификата нет или срок действия существующего скоро истечет, устройство сгенерирует пару ключей и запрос на подпись сертификата (CSR), используя назначенное ему имя хоста (здесь: xi8qz.example.com) в качестве CN, и оно отправит этот CSR на управляющий сервер (шаг 5).
После авторизации запроса (важный шаг, не показанный на схеме!), Управляющий сервер запрашивает DNS-запрос для данного домена из ACME API через вызов Pre-Authorization / new-authz API (шаг 6). ACME API отвечает запросом DNS (шаг 7). Если все идет хорошо, это выглядит примерно так:
{
"identifier": {
"type": "dns",
"value": "xi8qz.example.com"
},
"status": "pending",
"expires": "2018-04-15T21:26:29Z",
"challenges": [
{
"type": "dns-01",
"status": "pending",
"uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/VtjihR4X8nLAj4MDwI...",
"token": "aLptEKAeUOajkiGrx-kkbjUX4b1MC..."
},
// ...
],
// ...
}
Используя этот ответ, управляющий сервер должен установить запись DNS TXT на _acme-challenge.xi8qz.example.com (шаг 8) и уведомить ACME API о том, что ответ на запрос был размещен (шаг 9).
После того, как ответ на запрос был проверен с помощью Let's Encrypt (шаг 10-11), сертификат можно, наконец, запросить с помощью CSR (шаг 12-13).
После того, как Let's Encrypt ответит сертификатом, вы увидите на проводе что-то вроде этого:
-----BEGIN CERTIFICATE-----
MIIGEjCCBPqgAwIBAgISAyk2izMz7OXSqHeZhg+rUR5uMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
...
Если декодировать с помощью openssl, мы увидим, что это настоящая сделка:
$ openssl x509 -in www.crt -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
03:29:36:8b:33:33:ec:e5:d2:a8:77:99:86:0f:ab:51:1e:6e
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Validity
Not Before: Jul 18 23:37:35 2018 GMT
Not After : Oct 16 23:37:35 2018 GMT
Subject: CN=xi8qz.example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:be:69:df:28:04:9c:2b:e9:94:72:c3:de:a6:fd:
a4:38:93:be:43:a7:81:8b:dc:9a:be:19:0d:c0:d1:
...
Этот сертификат затем возвращается в машину (шаг 14). После перезапуска веб-сервера устройства / сервера к его веб-интерфейсу можно будет получить доступ через HTTPS в браузере или из командной строки:
$ curl -v https://xi8qz.example.com/login
* Trying 10.1.1.4...
* TCP_NODELAY set
* Connected to xi8qz.example.com (10.1.1.4) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=xi8qz.example.com
* start date: Jul 18 23:37:35 2018 GMT
* expire date: Oct 16 23:37:35 2018 GMT
* subjectAltName: host "xi8qz.example.com" matched cert's "xi8qz.example.com"
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
> GET /login HTTP/1.1
> Host: xi8qz.example.com
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Sun, 05 Aug 2018 17:38:49 GMT
< Server: Apache/2.4.18 (Ubuntu)
...
- Рекомендации по развертыванию: ограничения скорости Let's Encrypt.
Важно отметить, что если вы планируете реализовать этот механизм для большого количества серверов, вы используете staging среды Let's Encrypt для тестирования и, что более важно, учитываете лимиты выдачи сертификатов.
По умолчанию Let's Encrypt позволяет выдавать только 20 сертификатов (в 2018 году) в неделю для одного и того же домена или одной и той же учетной записи. Чтобы увеличить это число, вы должны либо запросить более высокий лимит выдачи, либо добавить свой домен в список общедоступных суффиксов (обратите внимание: добавление вашего домена здесь имеет другие последствия!).
Из-за этих ограничений скорости жизненно важно, чтобы вы распределили начальное развертывание настолько, чтобы оставаться ниже ограничения скорости, и чтобы вы оставили достаточно места для добавления будущих серверов. Также рассмотрите возможность продления в первоначальном плане развертывания. - Резюме
Как видите, это не так уж и сложно.
Сначала мы присвоили каждому устройству (так называемому внутреннему серверу) публичное доменное имя, используя наш собственный динамический DNS-сервер и выделенную зону DNS. Используя домен, назначенный серверу (здесь: xi8qz.example.com), мы затем использовали предложение бесплатного сертификата Let's Encrypt и их запрос DNS, чтобы выпустить сертификат для этого сервера.
Сделав это для всех внутренних серверов, мы можем обеспечить безопасную связь в нашей внутренней ИТ-инфраструктуре без необходимости развертывания настраиваемого сертификата CA или необходимости платить за сертификаты.
Интересные Github проекты по этой теме:
https://github.com/RealTimeLogic/SharkTrust
https://github.com/joohoi/acme-dns
https://github.com/skoerfgen/CertLE
https://github.com/Corollarium/localtls
Источник статьи: https://habr.com/ru/post/568378/