Let's encrypt за относительно короткий промежуток времени стал самым популярным в мире центром сертификации (CA) по выпуску TLS-сертификатов. Причиной тому является, во-первых, бесплатность получения сертификата для любого желающего и, во-вторых, удобный механизм его выпуска и продления, когда благодаря множеству способов и программных средств данный процесс можно легко автоматизировать.
Сегодня Let's Encrypt занимает свыше 2/3 общего объёма видимых в Интернет TLS-сертификатов и доля его растёт.
Однако, до недавнего времени эта динамика несколько сдерживалась отсутствием возможности получить т.н. wildcard-сертификат, то есть такой, который покрывает все поддомены в рамках существующего домена более высокого уровня. Несмотря на то, что стандартный механизм Let's Encrypt позволяет иметь в одном сертификате до 200 различных доменов через расширени TLS SNI, это далеко не всегда удобно, ведь для каждого нового домена приходилось включать его в состав уже имеющегося сертификата или выпускать новый.
Ситуация изменилась в марте 2018 года, когда был официально запущен новый протокол и API к нему ACMEv2, одним из ключевых новшеств которого стало появление возможности выпуска wildcard-сертификатов.
Новинка не имеет обратной совместимости с предыдущей версией ACMEv1. В этой связи все ныне действительные сертификаты не могут быть конвертированы в wildcard-версию. Для получения такого сертификата необходим повторный выпуск при помощи одного из поддерживающих новый протокол клиента, включая и официальный certbot, который начиная с версии 0.22 может работать по ACMEv2.
Автор давно, широко и активно использует сертификаты Let's encrypt в своих проектах и о многих аспектах использования неоднократно писалось на страницах этого блога, как то, к примеру, работа механизмов HPKP и DANE. В этой связи, миграция на wildcard-сертификаты может стать проблематичной.
Рассмотрим, как это можно осуществить с минимальными затратами и без разрывов в обслуживании клиентов, использующих TLS с сертификатами от Let's Encrypt.
Традиционно в клиентах Let's encrypt пооддерживается несколько способов подтверждения владения доменом, которое необходимо для авторизации выпуска TLS-сертификата. Все они предполагают размещение специального проверочного кода, доступного по протоколу HTTP или посредством DNS-запроса, для каждого из доменов, который предполагается включить в выпускаемый сертификат.
Понятно, что для wildcard-сертификатов такой подход не имеет смысла, поскольку невозможно заранее знать, какие поддомены и когда будут созданы. Следовательно, требуется механизм, который удостоверит владение доменом, для которого выпускается такой сертификат. На момент написания статьи единственным способом предлагаемым ACMEv2 является метод dns-01, основанный на подтверждении владения (управления) DNS-сервером, который поддерживает данный домен.
При этом клиент Let's Encrypt размещает специальную TXT-запись формата
_acme-challenge.my.domain. 300 IN TXT "HhY6js...7hdGj6"
и обращается к ней для соответствующей проверки.
В официальном клиенте Let's encrypt certbot это реализуется через встроенное расширение DNS Plugins. Они представляют собой набор API к популярным DNS-хостингам, таким, например, как Cloudflare или Amazon Route53, которые позволяют разместить проверочный код в DNS-зоне домена и осуществить требуемую авторизацию выпуска TLS-сертификата без участия пользователя.
Для использующих свой собственный первичный DNS сервер, к числу которых относится и автор, реализован и метод с использованием механизма DNS TSIG который описан в стандарте RFC2845 и представляющий собой механизм аутентификации при динамическом обновении DNS записей (см. текущую редакцию стандарта RFC2136).
Рассмотрим практическую реализацию миграции на wildcard-сертификаты на уже действующей системе использующий протокол предыдущего поколения ACMEv1.
Напомню, что автор использует DNS-сервер NSD в среде FreeBSD.
root@my:~ # uname -v
FreeBSD 11.1-RELEASE-p8 #0: Tue Mar 13 17:07:05 UTC 2018 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
root@my:~ # nsd -v
NSD version 4.1.17
Written by NLnet Labs.
Copyright (C) 2001-2006 NLnet Labs. This is free software.
There is NO warranty; not even for MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.
К сожалению, несмотря на поддержку механизма аутентификации TSIG, текущая версия NSD не поддерживает запросы RFC2136, поэтому воспользоваться соответствующим функционалом certbot, к сожалению, не удастся. Однако, в том случае, если клиент Let's encrypt будет запускаться на той же системе, можно неспосредственно добавлять проверочную запись в файл соответствующей DNS-зоны.
Для этих целей воспользуемся специальными хуками (hooks) --manual-auth-hook и --manual-cleanup-hook клиента certbot, которые позволяют, соответственно, до выполнения процедуры подтверждения владения доменом и после неё запустить внешние скрипты. При запуске формируются специальные переменные окружения, используя значения которых имеется возможность получить все необходимые данные.
Напишем пару скриптов — для добавления проверочной записи в зону домена и удаления её после окончания проверки. Ввиду того, что используется DNSSEC в качестве вспомогательных средств будут использованы скрипты dnstool из статьи "Поддержка DNSSEC и ротация ключей цифровой подписи" доступные также на Github автора.
root@my:~ # cd /usr/local/etc/nsd/
root@my:/usr/local/etc/nsd # touch leadd.sh ledel.sh
root@my:/usr/local/etc/nsd # chmod +x le*.sh
...
root@my:/usr/local/etc/nsd # cat leadd.sh
#!/bin/sh
# Add Let's encrypt validation code to DNSSEC zone
# v.20180325 2018 (c) Max Kostikov http://kostikov.co e-mail: max@kostikov.co
#
nsddir="/usr/local/etc/nsd"
maindom=`echo $CERTBOT_DOMAIN | sed -r 's/.*\.([^.]+\.[^.]+)$/\1/'`
subdom=`echo $CERTBOT_DOMAIN | sed -r 's/(.+)\.[^.]+\.[^.]+$/\1/'`
if [ "$maindom" == "$subdom" ]
then
str="_acme-challenge IN TXT \"$CERTBOT_VALIDATION\""
else
str="_acme-challenge.$subdom IN TXT \"$CERTBOT_VALIDATION\""
fi
zone="${nsddir}/zones/${maindom}/${maindom}.zone"
echo $str >> $zone
${nsddir}/dnsnewserial.sh $zone
${nsddir}/dnssignzone.sh $zone
nsd-control reload $maindom
sleep 10
root@my:/usr/local/etc/nsd # cat ledel.sh
#!/bin/sh
# Delete Let's encrypt validation code from DNSSEC zone
# v.20180325 2018 (c) Max Kostikov http://kostikov.co e-mail: max@kostikov.co
#
nsddir="/usr/local/etc/nsd"
zone="${nsddir}/zones/${CERTBOT_DOMAIN}/${CERTBOT_DOMAIN}.zone"
[ `grep "acme-challenge" $zone | wc -l` -eq 0 ] && exit
sed -i.bak '/^_acme-challenge/d' $zone
${nsddir}/dnsnewserial.sh $zone
${nsddir}/dnssignzone.sh $zone
nsd-control reload $CERTBOT_DOMAIN
Скрипты расположены в рабочем каталоге NSD /usr/local/etc/nsd и носят названия leadd.sh и ledel.sh.
Если вы не используете DNSSEC то достаточно исключить из текста обоих скриптов запуск процедуры подписи зоны dnssignzone.sh.
В случае, если вы используете DNS-записи CAA для управления политикой выдачи сертификатов центрами сертификации, следует убедиться что у вас разрешена выдача wildcard-сертификатов в ключе issuewild, где должно быть указано имя домена (см. статью "Использование DNS для управления выдачей SSL-сертификатов"). Для домена kostikov.co это разрешено.
root@beta:/usr/local/etc/nsd # host -t caa kostikov.co
kostikov.co has CAA record 0 issuewild "letsencrypt.org"
kostikov.co has CAA record 0 issue "letsencrypt.org"
kostikov.co has CAA record 0 iodef "mailto:abuse@peek.ru"
Теперь переведём домен на новый протокол ACMEv2. Для этого надо единожды запустить certbot и подтвердить переход на wildcard-сертификаты.
root@beta:/usr/local/etc/nsd # certbot certonly --manual --preferred-challenges=dns --manual-auth-hook /usr/local/etc/nsd/leadd.sh --manual-cleanup-hook /usr/local/etc/nsd/ledel.sh --manual-public-ip-logging-ok --agree-tos --email abuse@kostikov.co --cert-name kostikov.co -d kostikov.co -d "*.kostikov.co" --server https://acme-v02.api.letsencrypt.org/directory
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
-------------------------------------------------------------------------------
You are updating certificate peek.ru to include new domain(s):
+ *.kostikov.co
You are also removing previously included domain(s):
- kostikov.co
- www.kostikov.co
Did you intend to make this change?
-------------------------------------------------------------------------------
(U)pdate cert/(C)ancel: U
Renewing an existing certificate
Performing the following challenges:
dns-01 challenge for kostikov.co
dns-01 challenge for kostikov.co
Output from leadd.sh:
2018032910
Kkostikov.co.+013+53618 Kkostikov.co.+013+47047
ok
Output from leadd.sh:
2018032911
Kkostikov.co.+013+53618 Kkostikov.co.+013+47047
ok
Waiting for verification...
Cleaning up challenges
Output from ledel.sh:
2018032912
Kkostikov.co.+013+53618 Kkostikov.co.+013+47047
ok
Output from ledel.sh:
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/usr/local/etc/letsencrypt/live/kostikov.co/fullchain.pem
Your key file has been saved at:
/usr/local/etc/letsencrypt/live/kostikov.co/privkey.pem
Your cert will expire on 2018-06-27. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew *all* of your certificates, run
"certbot renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
В выводе скриптов-хуков можно увидеть, как зоне присваивается новый серийный номер, одна подписывается текущим актуальным набором ключей KSK и ZSK, а измнения успешно принимаются DNS сервером.
Если вы не перевыпускаете, а собираетесь впервые получить wildcard-сертификат Let's Encrypt для своего домена то из приведённой строки запуска достаточно будет исключить ключ --cert-name и его параметр в виде доменного имени.
Просмотрим содержимое нового wildcard-сертификата.
root@beta:/usr/local/etc/nsd # openssl x509 -in ../letsencrypt/live/kostikov.co/cert.pem -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
03:c0:1d:98:54:d8:df:38:4e:8c:e7:56:c8:b3:0b:79:78:ec
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Validity
Not Before: Mar 29 19:40:19 2018 GMT
Not After : Jun 27 19:40:19 2018 GMT
Subject: CN=kostikov.co
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d9:3d:6a:9f:2d:34:df:f3:00:61:f7:f2:8a:fa:
5d:51:44:8e:f5:d7:62:6f:f0:7a:49:b2:36:4f:2c:
93:eb:c1:e9:e4:82:8e:36:7a:93:58:1c:a6:3d:f8:
54:64:c0:5a:d5:d6:67:0f:13:2b:77:83:23:23:8a:
bf:8e:b0:29:4a:33:eb:89:e8:f9:30:0b:ff:2b:3d:
07:ed:af:c6:aa:ed:98:a5:96:3e:1b:db:4c:14:3b:
87:14:41:80:94:09:38:74:86:e9:33:21:f2:67:87:
57:cb:bc:a2:96:c3:7c:ae:de:c4:62:d2:69:e8:61:
bb:79:24:8f:4a:7e:39:54:c6:d1:4f:56:79:89:6e:
eb:a1:04:1f:c6:0d:3d:00:16:59:23:ab:63:08:9a:
35:4c:91:c4:fa:dd:36:64:2e:b7:bb:58:b6:48:2a:
8f:6a:de:52:70:7d:02:8b:52:76:ac:1e:17:73:f4:
47:86:bb:1a:f4:f8:fa:73:4b:c4:57:c4:66:3f:e7:
0a:1f:56:b7:74:fd:a0:70:71:46:60:c1:57:89:08:
76:70:4d:0a:91:6f:74:34:de:7e:76:74:67:d9:9c:
62:de:c9:c4:3c:02:49:15:fe:78:44:4b:c3:d4:f5:
cb:a1:66:d7:96:06:8b:67:21:8e:00:7d:d8:44:78:
2a:d1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
5A:C0:46:5D:8D:54:9A:B7:27:84:26:7B:A6:52:0F:B5:1C:C2:E8:6E
X509v3 Authority Key Identifier:
keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1
Authority Information Access:
OCSP - URI:http://ocsp.int-x3.letsencrypt.org
CA Issuers - URI:http://cert.int-x3.letsencrypt.org/
X509v3 Subject Alternative Name:
DNS:*.kostikov.co, DNS:kostikov.co
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.44947.1.1.1
CPS: http://cps.letsencrypt.org
User Notice:
Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at https://letsencrypt.org/repository/
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1(0)
Log ID : 55:81:D4:C2:16:90:36:01:4A:EA:0B:9B:57:3C:53:F0:
C0:E4:38:78:70:25:08:17:2F:A3:AA:1D:07:13:D3:0C
Timestamp : Mar 29 20:40:19.542 2018 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:20:15:AF:C6:45:9D:5A:F6:89:EC:B3:8D:3B:
1D:3F:8D:2F:1E:36:61:67:5B:43:91:DC:53:FC:9B:63:
2C:53:07:82:02:21:00:95:9E:18:A1:34:48:84:8E:36:
22:9C:53:F8:8D:85:34:58:8C:7A:34:48:E4:2C:41:96:
3A:E4:CB:6A:A4:E8:95
Signed Certificate Timestamp:
Version : v1(0)
Log ID : 29:3C:51:96:54:C8:39:65:BA:AA:50:FC:58:07:D4:B7:
6F:BF:58:7A:29:72:DC:A4:C3:0C:F4:E5:45:47:F4:78
Timestamp : Mar 29 20:40:19.553 2018 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:20:7A:74:24:4A:47:EC:A0:D5:86:EE:80:D2:
74:63:3A:0E:79:89:77:FC:89:D7:4F:0F:CF:84:0D:7B:
82:B2:16:5F:02:21:00:D6:30:B7:EF:76:3C:5C:CC:6E:
11:90:B7:7E:A9:16:83:7A:4B:75:45:CF:11:B2:BC:63:
8D:39:D8:E0:BF:F4:5E
Signature Algorithm: sha256WithRSAEncryption
84:a1:29:81:24:a2:44:b3:f8:f4:08:df:c0:65:25:5e:f9:e9:
d1:c6:06:b4:65:9c:d6:b2:a4:9d:28:d2:7f:8d:87:42:cd:95:
5e:27:43:4e:ae:a3:04:9e:29:38:ab:35:55:51:66:38:06:83:
71:a7:61:6a:c7:23:29:14:a2:50:19:a4:24:d2:0d:e1:2a:f5:
b3:a9:8e:a7:d6:8b:05:e6:64:59:a7:6b:2d:fd:d1:43:97:6b:
37:91:06:af:2f:79:46:27:4f:58:84:04:5b:39:e0:a1:9e:74:
24:f6:54:5c:95:fa:4b:8c:48:37:5c:e4:77:af:59:db:7b:0b:
97:c2:03:d8:04:01:50:04:ef:5a:23:82:f9:9d:46:04:2b:5a:
86:4a:4b:af:0b:35:82:fb:68:b1:45:e3:2f:1a:aa:a1:d7:d3:
01:68:1a:f6:87:d0:24:cf:b3:b9:bc:91:70:09:58:a7:66:30:
83:2b:a3:2f:c2:68:42:f6:6d:d3:9e:51:a0:58:79:e1:25:60:
fa:24:54:dd:50:3d:af:cc:da:3d:a0:bc:0a:55:1e:c5:5a:8f:
db:b0:32:dd:52:a2:a1:10:14:ff:20:7d:ba:83:c9:0d:9b:5f:
d1:86:ab:8a:48:66:bd:d8:2a:5b:eb:d3:dc:f5:01:58:06:8c:
e8:88:d5:b5
-----BEGIN CERTIFICATE-----
MIIGEDCCBPigAwIBAgISA8AdmFTY3zhOjOdWyLMLeXjsMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xODAzMjkxOTQwMTlaFw0x
ODA2MjcxOTQwMTlaMBYxFDASBgNVBAMTC2tvc3Rpa292LmNvMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2T1qny003/MAYffyivpdUUSO9ddib/B6SbI2
TyyT68Hp5IKONnqTWBymPfhUZMBa1dZnDxMrd4MjI4q/jrApSjPriej5MAv/Kz0H
7a/Gqu2YpZY+G9tMFDuHFEGAlAk4dIbpMyHyZ4dXy7yilsN8rt7EYtJp6GG7eSSP
Sn45VMbRT1Z5iW7roQQfxg09ABZZI6tjCJo1TJHE+t02ZC63u1i2SCqPat5ScH0C
i1J2rB4Xc/RHhrsa9Pj6c0vEV8RmP+cKH1a3dP2gcHFGYMFXiQh2cE0KkW90NN5+
dnRn2Zxi3snEPAJJFf54REvD1PXLoWbXlgaLZyGOAH3YRHgq0QIDAQABo4IDIjCC
Ax4wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcD
AjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBRawEZdjVSatyeEJnumUg+1HMLobjAf
BgNVHSMEGDAWgBSoSmpjBH3duubRObemRWXv86jsoTBvBggrBgEFBQcBAQRjMGEw
LgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwLmludC14My5sZXRzZW5jcnlwdC5vcmcw
LwYIKwYBBQUHMAKGI2h0dHA6Ly9jZXJ0LmludC14My5sZXRzZW5jcnlwdC5vcmcv
MCUGA1UdEQQeMByCDSoua29zdGlrb3YuY2+CC2tvc3Rpa292LmNvMIH+BgNVHSAE
gfYwgfMwCAYGZ4EMAQIBMIHmBgsrBgEEAYLfEwEBATCB1jAmBggrBgEFBQcCARYa
aHR0cDovL2Nwcy5sZXRzZW5jcnlwdC5vcmcwgasGCCsGAQUFBwICMIGeDIGbVGhp
cyBDZXJ0aWZpY2F0ZSBtYXkgb25seSBiZSByZWxpZWQgdXBvbiBieSBSZWx5aW5n
IFBhcnRpZXMgYW5kIG9ubHkgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBDZXJ0aWZp
Y2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0cHM6Ly9sZXRzZW5jcnlwdC5vcmcvcmVw
b3NpdG9yeS8wggEEBgorBgEEAdZ5AgQCBIH1BIHyAPAAdgBVgdTCFpA2AUrqC5tX
PFPwwOQ4eHAlCBcvo6odBxPTDAAAAWJzfWFWAAAEAwBHMEUCIBWvxkWdWvaJ7LON
Ox0/jS8eNmFnW0OR3FP8m2MsUweCAiEAlZ4YoTRIhI42IpxT+I2FNFiMejRI5CxB
ljrky2qk6JUAdgApPFGWVMg5ZbqqUPxYB9S3b79Yeily3KTDDPTlRUf0eAAAAWJz
fWFhAAAEAwBHMEUCIHp0JEpH7KDVhu6A0nRjOg55iXf8iddPD8+EDXuCshZfAiEA
1jC373Y8XMxuEZC3fqkWg3pLdUXPEbK8Y4052OC/9F4wDQYJKoZIhvcNAQELBQAD
ggEBAIShKYEkokSz+PQI38BlJV756dHGBrRlnNaypJ0o0n+Nh0LNlV4nQ06uowSe
KTirNVVRZjgGg3GnYWrHIykUolAZpCTSDeEq9bOpjqfWiwXmZFmnay390UOXazeR
Bq8veUYnT1iEBFs54KGedCT2VFyV+kuMSDdc5HevWdt7C5fCA9gEAVAE71ojgvmd
RgQrWoZKS68LNYL7aLFF4y8aqqHX0wFoGvaH0CTPs7m8kXAJWKdmMIMroy/CaEL2
bdOeUaBYeeElYPokVN1QPa/M2j2gvApVHsVaj9uwMt1SoqEQFP8gfbqDyQ2bX9GG
q4pIZr3YKlvr09z1AVgGjOiI1bU=
-----END CERTIFICATE-----
Как видно, как основной домен, так и все поддомены в виде wildcard присутствуют в поле Subject Alternative Name.
Также можно проверить параметры автоматического обновления, которые были сформированы при выпуске и фигурируют в конфигурационном файле расположенном в каталоге /usr/local/etc/letsencrypt/renewal/.
root@my:/usr/local/etc/nsd # cat /usr/local/etc/letsencrypt/renewal/kostikov.co.conf
renew_before_expiry = 60 days
version = 0.22.2
archive_dir = /usr/local/etc/letsencrypt/archive/kostikov.co
cert = /usr/local/etc/letsencrypt/live/kostikov.co/cert.pem
privkey = /usr/local/etc/letsencrypt/live/kostikov.co/privkey.pem
chain = /usr/local/etc/letsencrypt/live/kostikov.co/chain.pem
fullchain = /usr/local/etc/letsencrypt/live/kostikov.co/fullchain.pem
# Options used in the renewal process
[renewalparams]
account = fb0779fb7991fff119eb378df718ac2a
manual_public_ip_logging_ok = True
manual_auth_hook = /usr/local/etc/nsd/leadd.sh
manual-cleanup-hook = /usr/local/etc/nsd/ledel.sh
server = https://acme-v02.api.letsencrypt.org/directory
authenticator = manual
installer = None
pref_challs = dns-01,
В дальнейшем обновление будет производиться стандартным способом при помощи команды certbot renew, которая может быть запущена и в cron.
root@my:/usr/local/etc/nsd # grep certbot /etc/crontab
0 3 * * 0 root /usr/local/bin/certbot renew >/dev/null 2>&1
Как уже упоминалось выше, автор использует довольно продвинутые способы применения сертификатов Let's Encrypt, генерируя на их базе цифровые отпечатки для HPKP и DANE и обеспечивалась непрерывность функционирования систем при обновлении сертификатов. Для этой цели используется специально разработанный shell-скрипт lerenew.sh последний вариант (прим. — на самом деле, не последний) которого был описан в статье "Технология DANE — безопасность через DNS".
Для продолжения гладкой работы уже отстроенной системы после получения нового TLS-сертификата следует лишь запустить этот скрипт для обновления необходимых данных.
root@my:/usr/local/etc/nsd # cd ../letsencrypt
root@my:/usr/local/etc/letsencrypt # ./lerenew.sh
writing RSA key
writing RSA key
2018032912
Kkostikov.co.+013+53618 Kkostikov.co.+013+4704711
ok
Stopping h2o.
Waiting for PIDS: 98902.
Starting h2o.
start_server (pid:18357) starting now...
Stopping dovecot.
Waiting for PIDS: 68010.
Starting dovecot.
Stopping exim.
Starting exim.
Далее никаких измнений не потребуется и процесс обновления будет происходить в штатном режиме.
Статья была полезной? Тогда прошу не стесняться и поддерживать деньгами через PayPal, Яндекс.Деньги. или через замечательную систему Patreon.