- Истек сертификат let’s encrypt. что делать?
- Почему лучше рассчитывать на sni?
- Alternate webserver mode
- Caveat emptor
- Contributors
- Disclaimer of warranty
- Error: letsencrypt challenge request 429
- Error: port check failed
- First run
- How it works
- How to manually install/renew let’s encrypt ssl in zimbra – mellowhost blog
- License
- Limitations
- Nginx
- Preparation
- Renewal using crontab
- Renewal using systemd
- Rewrite
- Upgrade from v0.1
- Usage
- Warning
- Zimbra-proxy mode (the default)
- Автообновление сертификатов let’s encrypt
- В примере будем использовать сервер с debian 9 и nginx в качестве веб-сервер.
- Вот и всё
- Выпуск и настройка сертификата для панели управления vestacp
- Если нужно добавить поддомен или домен в сертификат
- Если нужно получить сертификат для домена без сайта…
- Как это работает
- Немного лирики
- Обновление/установка сертификата на ос windows xp, vista, 7
- Обязательные требования
- Пара слов о «граблях»
- Подготовим nginx к получению сертификатов
- Получаем сертификаты
- Проверим полученный сертификат
- Проверка сертификатов
- Продление сертификатов
- Процесс по шагам
- Установка в jessie
- Установка сертификатов
- Часть 2: создание в iis сайта для доступа к серверу worldclient
- Часть 5: удаление всех следов «тестовой» жизнедеятельности
- Часть 7: первый «боевой» запуск
- Часть последняя — заключительная
- Шаг 2. остановите службу прокси zimbra
- Шаг 3: получим ssl-сертификат lets encrypt
Истек сертификат let’s encrypt. что делать?
Утро, понедельник, приходит письмо от клиента со скриншотом и сакраментальным «Что делать?».
Вдумайтесь, только зашел на сайт, еще ничего не сделал, а тут толпы злоумышленников во всю трясут с тебя пароли, сообщения, кредитные карты, деньги, золото, бриллианты. Страх и ужОс.
Примечательно то, что дело происходит летом, сертификат ставил сотрудник, который давно работает не с нами, а босс в отпуске. В общем, типичный, веселый, белый, пушистый, подкрадывающийся незаметно северный зверёк.
Но нам не привыкать.
Внимание! Всё, что будет рассказываться дальше, очень опасно в руках растущих не из того места. Чисто теоретически: бездумно пытаясь сделать так, как написано в посте, вы можете повредить сайт, сервер и собственный мозг. Поэтому, если не понимаете что и как делалось, а главное для чего, то не стоит даже пытаться. Обратитесь к
квалифицированному врачу
специалисту.
Но если все-таки что-то пошло не так, то я тут не при чем, а значит, все претензии к себе-любимому.
Я принимаю только благодарности и только финансовые. Хотя…
Во-первых, смотрим подробности сертификата.
Из этих подробностей выясняем, что это Let’s Encrypt, и что сертификат истек 29 июня. Сегодня 1 июля! Значит все правильно. Нужно просто перевыпстить сертификат.
Let’s Encrypt — центр сертификации, который раздает бесплатные криптографические сертификаты X.509 для TLS-шифрования (HTTPS). Выдача сертификатов полностью автоматизирована (пишет нам википедия).
Лезем на 2ip.ru и выясняем, где припаркован домен. Кстати, картинки кликабельны.
Какой кошмар. Домен припаркован в Российской Федерации! Опять этот «русский след». Прекрасно!)
Что мы видим? Мы видим IP хоста, мы видим название Хостера (Таймвеб, в данном случае). Осталось обыскать наши базы паролей и…
Да! Доступы в панель управления хостингом у нас есть.
Заходим и… выясняем, что такого домена, в панели управления хостингом, нет. Никакой сертификат там не привязан… Ну ооооок.
Лезем на сервер по SSH.
Зачем? Поскольку в Let’s Encrypt выдача сертификатов полностью автоматизирована, значит мы точно найдем задание для Cron, на обновление сертификатов. Чтобы найти все задачи крона, вводим в консоль команду crontab -l
Вот что мы на это получаем:
CONTENT_TYPE="text/plain; charset=utf-8" 15 02 * * * sudo /usr/local/vesta/bin/v-update-sys-queue disk 10 00 * * * sudo /usr/local/vesta/bin/v-update-sys-queue traffic 30 03 * * * sudo /usr/local/vesta/bin/v-update-sys-queue webstats */5 * * * * sudo /usr/local/vesta/bin/v-update-sys-queue backup 10 05 * * * sudo /usr/local/vesta/bin/v-backup-users 20 00 * * * sudo /usr/local/vesta/bin/v-update-user-stats */5 * * * * sudo /usr/local/vesta/bin/v-update-sys-rrd 31 7 * * * sudo /usr/local/vesta/bin/v-update-sys-vesta-all 52 2 * * * sudo /usr/local/vesta/bin/v-update-letsencrypt-ssl
Что нам это дает? Ну, во-первых, мы видим строку с ключевыми словами update и letsencrypt. Значит этот скрипт и обновляет сертификат, а чтобы его запустить, просто введем в консоль команду sudo /usr/local/vesta/bin/v-update-letsencrypt-ssl
Собственно, вводим и получаем вот что:
domain.ru Error: domain alias domain.ru doesn’t exist
В примерном переводе это означает: Что-то там пошло не так, и я не могу обновить сертификат автоматически. Крутитесь дальше как хотите.
Тогда нам остается то самое во-вторых. В задачах крона мы видим ключевое слово vesta. А Vesta CP — это панель управления сервером. Похоже, кто-то накатил ее на VPS. Значит домен наверняка привязан в ней.
Зайти в Vesta CP (а значит доказать ее наличие) довольно легко: в адресную строку браузера вписываем https://IP_Адрес:8083/list/user/
Само-собой, вместо IP_Адрес вставляем тот IP, который подсмотрели на 2IP.RU.
Отлично. Домен найден, а в редактировании мы видим и настройки сертификата.
Раз автоматическое обновление не работает — обновим вручную.
Делай раз: Снимаем галочку в чекбоксе «Поддержка SSL» и сохраняем.
Делай два: Ставим галочку в чекбоксе «Поддержка SSL» и сохраняем.
Всё. Сертификат продлен до 29 сентября и браузер пугающих надписей клиенту больше не показывает. Пока.
Дело сделано. Осталось выпить чашечку горячего ароматного, и продолжить работу. Солнце-то, все еще высоко. Лето…
А чтобы тот «комсомолец», которому 29 сентября прилетит «письмо счастья» от клиента, не искал решение слишком долго, я написал этот пост. Ну и всем остальным, кто (ну мало-ли) столкнется с истекшим сертификатом от Let’s Encrypt, этот пост тоже пригодится.
Почему лучше рассчитывать на sni?
Это просто. Вам не нужно постоянно держать в голове факты о выданных сертификатах. Для какого домена сертификат был выдан первым. К какому сертификату нужно добавлять еще домены. И так далее… Ни о чем таком со SNI не нужно думать.
- Секреты остаются секретами. Если у вас для всех доменов один сертификат, то любой сможет очень легко увидеть весь список, независимо от вашего желания. Если же для каждого сайта свой сертификат, то такой проблемы нет.
Например, так можно посмотреть домены в сертификате Тематических Медиа:
Alternate webserver mode
Is selected with -x/–no-nginx. Requires -P/–port and -w/–webroot. –port is checked for listening status. All zimbra-proxy checks are skipped.
Can be used in case you don’t have zimbra-proxy enabled but have a different webserver as a reverse proxy in front of Zimbra.
You’ll have to configure the webserver for letsencrypt (to serve /.well-known from a webroot somewhere in the filesystem), some examples for this can be found here.
Renewal can be done as per instructions below, but –pre-hook can be omitted.
Caveat emptor
Всё знаете про SNI? Читайте сразу про установку.
Contributors
- Jernej Jakob @jjakob
- @eN0RM
- Pavel Pulec @pulecp
- Antonio Prado
- @afrimberger
- @mauriziomarini
if you are a contributor, add yourself here (and in the code)
Feedback, bugs, PR are welcome on GitHub.
Disclaimer of warranty
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Error: letsencrypt challenge request 429
- Попробуйте удалить домен из панели VestaCP и добавить его снова, после чего повторить попытку выпуска сертификата.
- Повторите попытку выпуска сертификата через 1 час.
Error: port check failed
This usually means zimbra-proxy is misconfigured. In the default case (without port overrides) the script checks if zimbra-proxy’s nginx is listening on “zimbraMailProxyPort” (can be read with zmprov, port 80 in most cases). If this check fails, zimbra-proxy is misconfigured, not enabled, not started or you have a custom port configuration and didn’t tell the script via port override parameters.
First run
If you don’t yet have a letsencrypt certificate, you’ll need to obtain one first. The script can do everything for you, including deploying the certificate and restarting zimbra.
How it works
This script uses zimbra-proxy’s nginx to intercept requests to .well-known/acme-challenge and pass them to a custom webroot folder. To do this, we patch the templates Zimbra uses to build nginx’s configuration files.
The patch is simple, we add this new section to the end of the templates:
$WEBROOT is either /opt/zimbra/data/nginx/html (default) or the path specified by the command line option.
After this we restart zmproxy to apply the patches.
How to manually install/renew let’s encrypt ssl in zimbra – mellowhost blog
If you are having trouble installing Let’s Encrypt SSL with the certbot-zimbra.sh file, then probably you would need to follow this tutorial. To follow this tutorial, we first need to install certbot. certbot has a built in web server to allow you get the certificate without actually installing an extra web server or through Zimbra web server (nginx to be specific).
First, we install certbot with the following:
// install epel-release first yum install epel-release // install certbot from epel yum install certbot
Once done, you may now use the following command to ensure certbot is working:
# certbot --help
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...
Certbot can obtain and install HTTPS/TLS/SSL certificates. By default,
it will attempt to use a webserver both for obtaining and installing the
certificate. The most common SUBCOMMANDS and flags are:
obtain, install, and renew certificates:
(default) run Obtain & install a certificate in your current webserver
certonly Obtain or renew a certificate, but do not install it
renew Renew all previously obtained certificates that are near
expiry
enhance Add security enhancements to your existing configuration
-d DOMAINS Comma-separated list of domains to obtain a certificate for
(the certbot apache plugin is not installed)
--standalone Run a standalone webserver for authentication
--nginx Use the Nginx plugin for authentication & installation
--webroot Place files in a server's webroot folder for authentication
--manual Obtain certificates interactively, or using shell script
hooks
-n Run non-interactively
--test-cert Obtain a test certificate from a staging server
--dry-run Test "renew" or "certonly" without saving any certificates
to disk
manage certificates:
certificates Display information about certificates you have from Certbot
revoke Revoke a certificate (supply --cert-name or --cert-path)
delete Delete a certificate (supply --cert-name)
manage your account:
register Create an ACME account
unregister Deactivate an ACME account
update_account Update an ACME account
--agree-tos Agree to the ACME server's Subscriber Agreement
-m EMAIL Email address for important account notifications
More detailed help:
-h, --help [TOPIC] print this message, or detailed help on a topic;
the available TOPICS are:
all, automation, commands, paths, security, testing, or any of the
subcommands or plugins (certonly, renew, install, register, nginx,
apache, standalone, webroot, etc.)
-h all print a detailed help page including all topics
--version print the version number
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Once you ensure certbot is installed, now you may use certbot to get the certificate, using the certbot –standalone tag. Remember to stop zimbra first, as Zimbra also runs a nginx web server, that would prevent certbot to use standalone or it’s own web server to verify certificate.
// from root, run [[email protected] ~]# service zimbra stop // wait until zimbra stops, once done, use the following to get certificate for your domain/hostname in place of mail.domain.com [[email protected] ~]# certbot certonly --standalone -d mail.domain.com
This would get your certificate and save it in:
/etc/letsencrypt/live/mail.domain.com
Now, that folder would contain 4 files. Something like the following:
]# ls -la /etc/letsencrypt/live/mail.domain.com/ total 16 drwxr-xr-x 2 root root 4096 Apr 16 11:30 . drwx------ 4 root root 4096 Feb 10 2020 .. lrwxrwxrwx 1 root root 40 Apr 16 11:30 cert.pem -> ../../archive/mail.domain.com/cert8.pem lrwxrwxrwx 1 root root 41 Apr 16 11:30 chain.pem -> ../../archive/mail.domain.com/chain8.pem lrwxrwxrwx 1 root root 45 Apr 16 11:30 fullchain.pem -> ../../archive/mail.domain.com/fullchain8.pem lrwxrwxrwx 1 root root 43 Apr 16 11:30 privkey.pem -> ../../archive/mail.domain.com/privkey8.pem
As you can see, these files are symbolically linked to another files, depends on how many time you are running certbot. Each time, it generates a number liker cert8.pem, the next one would be cert9.pem and so on. So the orignal files are here:
/etc/letsencrypt/archive/mail.domain.com/cert8.pem /etc/letsencrypt/archive/mail.domain.com/chain8.pem /etc/letsencrypt/archive/mail.domain.com/fullchain8.pem /etc/letsencrypt/archive/mail.domain.com/privkey8.pem
Now, we have our certificates. We need to follow a couple of steps to make sure everything is set correctly.
First, zimbra SSL files are stored here
/etc/zimbra/ssl/letsencrypt
We clean all old pem files
rm -f /etc/zimbra/ssl/letsencrypt/*
Now, copy the pem files we got to this folder with the following:
cp /etc/letsencrypt/archive/mail.domain.com/cert8.pem /opt/zimbra/ssl/letsencrypt/cert.pem cp /etc/letsencrypt/archive/mail.domain.com/chain8.pem /opt/zimbra/ssl/letsencrypt/chain.pem cp /etc/letsencrypt/archive/mail.domain.com/fullchain8.pem /opt/zimbra/ssl/letsencrypt/fullchain.pem cp /etc/letsencrypt/archive/mail.domain.com/privkey8.pem /opt/zimbra/ssl/letsencrypt/privkey.pem
Check, how we are renaming all the files with number to file name without number, like cert8.pem is moved as cert.pem here.
Now, change the ownership of these files to zimbra with the following:
chown -Rf zimbra:zimbra /opt/zimbra/ssl/letsencrypt/*
Now, we are done from root, change your ownership to zimbra
su - zimbra
First job, is to change your directory to the ‘/opt/zimbra/ssl/letsencrypt/’
cd /opt/zimbra/ssl/letsencrypt/
Let’s Encrypt files are very much ready to use, only with one problem. Let’s Encrypt do not add it’s root CA certificate with it’s chain.pem file. We need to do this. First open the certificate with nano editor as following:
nano chain.pem
Now, at the end of the file, add the following section:
-----BEGIN CERTIFICATE----- MIIDSjCCAjKgAwIBAgIQRK wgNajJ7qJMDmGLvhAazANBgkqhkiG9w0BAQUFADA/ MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT DkRTVCBSb290IENBIFgzMB4XDTAwMDkzMDIxMTIxOVoXDTIxMDkzMDE0MDExNVow PzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMRcwFQYDVQQD Ew5EU1QgUm9vdCBDQSBYMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AN v6ZdQCINXtMxiZfaQguzH0yxrMMpb7NnDfcdAwRgUi DoM3ZJKuM/IUmTrE4O rz5Iy2Xu/NMhD2XSKtkyj4zl93ewEnu1lcCJo6m67XMuegwGMoOifooUMM0RoOEq OLl5CjH9UL2AZd 3UWODyOKIYepLYYHsUmu5ouJLGiifSKOeDNoJjj4XLh7dIN9b xiqKqy69cK3FCxolkHRyxXtqqzTWMIn/5WgTe1QLyNau7Fqckh49ZLOMxt /yUFw 7BZy1SbsOFU5Q9D8/RhcQPGX69Wam40dutolucbY38EVAjqr2m7xPi71XAicPNaD aeQQmxkqtilX4 U9m5/wAl0CAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFMSnsaR7LHH62 FLkHX/xBVghYkQMA0GCSqG SIb3DQEBBQUAA4IBAQCjGiybFwBcqR7uKGY3Or Dxz9LwwmglSBd49lZRNI DT69 ikugdB/OEIKcdBodfpga3csTS7MgROSR6cz8faXbauX 5v3gTt23ADq1cEmv8uXr AvHRAosZy5Q6XkjEGB5YGV8eAlrwDPGxrancWYaLbumR9YbK rlmM6pZW87ipxZz R8srzJmwN0jP41ZL9c8PDHIyh8bwRLtTcm1D9SZImlJnt1ir/md2cXjbDaJWFBM5 JDGFoqgCWjBH4d1QB7wCCZAA62RjYJsWvIjJEubSfZGL T0yjWW06XyxV3bqxbYo Ob8VZRzI9neWagqNdwvYkQsEjgfbKbYK7p2CNTUQ -----END CERTIFICATE-----
After adding the above, your chain.pem file should look like the following
-----BEGIN CERTIFICATE----- your chain pem encrypted certificate here -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDSjCCAjKgAwIBAgIQRK wgNajJ7qJMDmGLvhAazANBgkqhkiG9w0BAQUFADA/ MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT DkRTVCBSb290IENBIFgzMB4XDTAwMDkzMDIxMTIxOVoXDTIxMDkzMDE0MDExNVow PzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMRcwFQYDVQQD Ew5EU1QgUm9vdCBDQSBYMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AN v6ZdQCINXtMxiZfaQguzH0yxrMMpb7NnDfcdAwRgUi DoM3ZJKuM/IUmTrE4O rz5Iy2Xu/NMhD2XSKtkyj4zl93ewEnu1lcCJo6m67XMuegwGMoOifooUMM0RoOEq OLl5CjH9UL2AZd 3UWODyOKIYepLYYHsUmu5ouJLGiifSKOeDNoJjj4XLh7dIN9b xiqKqy69cK3FCxolkHRyxXtqqzTWMIn/5WgTe1QLyNau7Fqckh49ZLOMxt /yUFw 7BZy1SbsOFU5Q9D8/RhcQPGX69Wam40dutolucbY38EVAjqr2m7xPi71XAicPNaD aeQQmxkqtilX4 U9m5/wAl0CAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFMSnsaR7LHH62 FLkHX/xBVghYkQMA0GCSqG SIb3DQEBBQUAA4IBAQCjGiybFwBcqR7uKGY3Or Dxz9LwwmglSBd49lZRNI DT69 ikugdB/OEIKcdBodfpga3csTS7MgROSR6cz8faXbauX 5v3gTt23ADq1cEmv8uXr AvHRAosZy5Q6XkjEGB5YGV8eAlrwDPGxrancWYaLbumR9YbK rlmM6pZW87ipxZz R8srzJmwN0jP41ZL9c8PDHIyh8bwRLtTcm1D9SZImlJnt1ir/md2cXjbDaJWFBM5 JDGFoqgCWjBH4d1QB7wCCZAA62RjYJsWvIjJEubSfZGL T0yjWW06XyxV3bqxbYo Ob8VZRzI9neWagqNdwvYkQsEjgfbKbYK7p2CNTUQ -----END CERTIFICATE-----
Now, save the file (CTRL o) and exit (CTRL x)
We need to do one more thing before we are ready to verify and deploy the certificate. We need to set the letencrypt private key that we used to generate the certificate as commercial.key of zimbra. You may do this with the following two commands:
rm -f /opt/zimbra/ssl/zimbra/commercial/commercial.key cp /opt/zimbra/ssl/letsencrypt/privkey.pem /opt/zimbra/ssl/zimbra/commercial/commercial.key
Now, you are ready to complete the job. First verify if everything is alright with the following:
[[email protected] letsencrypt]$ /opt/zimbra/bin/zmcertmgr verifycrt comm privkey.pem cert.pem chain.pem
** Verifying 'cert.pem' against 'privkey.pem'
Certificate 'cert.pem' and private key 'privkey.pem' match.
** Verifying 'cert.pem' against 'chain.pem'
Valid certificate chain: cert.pem: OKIf everything is ok, you may now deploy certificate with the following command:
/opt/zimbra/bin/zmcertmgr deploycrt comm cert.pem chain.pem
Once the certificate is deployed successfully, get out from the zimbra user to root user with the following command
exit
Now, you may start/restart zimbra with the following command:
service zimbra restart
If everything went right, you should now be able to go to your zimbra domain, and under the lock sign on the left of the domain shown in browser, you may click on it to see the extended date of ssl expiry. Sweet!
License
See LICENSE.
Limitations
The script doesn’t handle multiple domains configured with SNI (see #8). You can still request a single certificate for multiple hostnames.
Nginx
Nginx – второй по популярности веб-сервер (и первый среди продвинутых пользователей) предполагает несколько иной подход к настройке. Для каждого виртуального хоста в секцию server следует добавить блок:
location ^~ /.well-known/acme-challenge/ {
default_type "text/plain";
root /var/www/letsencrypt;
}
location = /.well-known/acme-challenge/ {
return 404;
}Если вы настраивали сервер по нашей инструкции, то мы рекомендуем вынести указанный блок в отдельный шаблон, например, /etc/nginx/templates/letsencrypt.conf и впоследствии подключать в конфигурацию виртуального хоста именно его и в общих чертах это должно выглядеть так:
Preparation
The script needs some prerequisites. They are listed under Installation/Requirements. The script will run a prerequisite check on startup and exit if anthing is missing.
In addition, there are different modes of operation, depending on your environment (proxy server):
Renewal using crontab
EFF suggest to run renew twice a day. Since this would imply restarting zimbra, once a day outside workhours should be fine. So in your favourite place (like /etc/cron.d/zimbracrontab or with sudo crontab -e) schedule the command below, as suitable for your setup:
The –pre-hook ensures Zimbra’s nginx is patched to allow certificate verification. You can omit it if you remember to manually execute that command after an upgrade or a reinstall which may restore nginx’s templates to their default.
Renewal using systemd
If you prefer systemd you can use these instructions.
The example below uses the deploy-hook which will only rerun the script if a renewal was successful and thus only reloading zimbra when needed.
Sadly, systemd doesn’t have a built-in on-failure mail notification function like cron does so you won’t be notified of failed renewals. One could write a service to do that via “OnFailure=”.
Create a service file eg: /etc/systemd/system/renew-letsencrypt.service
Create a timer file to run the above once a day at 2am: /etc/systemd/system/renew-letsencrypt.timer
[Unit]
Description=Daily renewal of Let's Encrypt's certificates
[Timer]
# once a day, at 2AM
OnCalendar=*-*-* 02:00:00
# Be kind to the Let's Encrypt servers: add a random delay of 0–3600 seconds
RandomizedDelaySec=3600
Persistent=true
[Install]
WantedBy=timers.target
Then reload the unit file with
systemctl daemon-reload
systemctl start renew-letsencrypt.timer
systemctl enable renew-letsencrypt.timer
Check the timers status:
systemctl list-timers renew-letsencrypt.timer
Rewrite
Thanks to the awesome job of @jjakob the script has undergone a considerable rewrite.
Some things changed, some parameters have been renamed, so if you’re upgrading please read the WARNING chapter below.
We encourage you to test the script and report back any issues you might encounter. The latest version can be downloaded from the Releases tab, or if you prefer bleeding edge (may be broken) from the master branch directly.
If you encounter any problem please open an issue.
Things explicitly not tested are in the TESTING file.
USE AT YOUR OWN RISK.
Upgrade from v0.1
If you originally requested the certificate with the first version of the script, which used standalone method, newer version will fail to renew. This because it
now uses webroot mode by patching Zimbra’s nginx, making it more simple to work and to mantain.
To check if you have the old method, run grep authenticator /etc/letsencrypt/renewal/YOURDOMAIN.conf. If it says standalone it uses the old method.
Usage
USAGE: certbot_zimbra.sh < -d | -n | -p > [-aNuzjxcq] [-H my.host.name] [-e extra.domain.tld] [-w /var/www] [-s <service_names>] [-P port] [-L "--extra-le-parameters ..."]
Only one option at a time can be supplied. Options cannot be chained.
Mandatory options (only one can be specified):
-d | --deploy-only: Just deploys certificates. Can be run as --deploy-hook. If run standalone, assumes valid certificates are in /etc/letsencrypt/live. Incompatible with -n/--new, -p/--patch-only.
-n | --new: performs a request fora new certificate ("certonly"). Can be used to update the domainsin an existing certificate. Incompatible with -d/--deploy-only, -p/--patch-only.
-p | --patch-only: does only nginx patching. Useful to be called before renew, incase nginx templates have been overwritten by an upgrade. Incompatible with -d/--deploy-only, -n/--new, -x/--no-nginx.
Options only used with -n/--new:
-a | --agree-tos: agree with the Terms of Service of Let's Encrypt (avoids prompt) -L | --letsencrypt-params "--extra-le-parameters ...": Additional parameters to pass to certbot/letsencrypt -N | --noninteractive: Pass --noninteractive to certbot/letsencrypt. Domain options: -e | --extra-domain <extra.domain.tld>: additional domains being requested. Can be used multiple times. Implies -u/--no-public-hostname-detection. -H | --hostname <my.host.name>: hostname being requested. If not passed it's automatically detected using "zmhostname".
-u | --no-public-hostname-detection: do not detect additional hostnames from domains' zimbraServicePublicHostname. Deploy options: -s | --services <service_names>: the set of services to be used for a certificate. Valid services are 'all' or any of: ldap,mailboxd,mta,proxy. Default: 'all' -z | --no-zimbra-restart: do not restart zimbra after a certificate deployment Port check: -j | --no-port-check: disable port check. Incompatible with -P/--port. -P | --port <port>: HTTP port the web server to use for letsencrypt authentication is listening on. Is detected from zimbraMailProxyPort. Mandatory with -x/--no-nginx. Nginx options: -w | --webroot "/path/to/www": path to the webroot of alternate webserver. Valid only with -x/--no-nginx. -x | --no-nginx: Alternate webserver mode. Don't check and patch zimbra-proxy's nginx. Must also specify -P/--port and -w/--webroot. Incompatible with -p/--patch-only. Output options: -c | --prompt-confirm: ask for confirmation. Incompatible with -q/--quiet. -q | --quiet: Do not output on stdout. Useful for scripts. Implies -N/--noninteractive, incompatible with -c/--prompt-confirm.If no -e is given, the script will figure out the additional domain(s) to add to the certificate as SANs via zmprov gd $domain zimbraPublicServiceHostname.
This can be skipped with -u/–no-public-hostname-detection, in which case only the CN from zmhostname or -H/–hostname will be used.
Only one certificate will be issued including all the found hostnames. The primary host will always be zmhostname.
Warning
The command line parameters were changed with v0.7. -r/–renew-only was renamed to -d/–deploy-only, and -d was changed to -H. This is a BREAKING change so please update your crontabs and any other places they are used.
Zimbra-proxy mode (the default)
Uses zimbra-proxy for the letsencrypt authentication. Zimbra-proxy must be enabled and running. This is the preferred mode.
Автообновление сертификатов let’s encrypt
И очередной раз я посыпаю голову пеплом, так как вот уже около года на одном из моих пет-прожектов spaceismine.org протух Let’s Encrypt сертификат, а я даже и не думал шевелиться. Что ж, рано или поздно всё равно нужно исправляться. Приступаю.
Бегло заглянув на сайт этого замечательного проекта с бесплатными сертификатами, я отыскал нужный себе раздел и примерно понял, что нужно делать. Год развития проекта дал о себе знать, теперь существует прокачанная утилита, распространяемая через deb-пакет. Ставим её.
sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install letsencrypt
Да, приходится подключать отдельный PPA, так как в Ubuntu 16.04 (которая у меня) этот пакет довольно старый, и в нём нет поддержки ключа --post-hook, который нам понадобится ниже.
Судя по всему, написано там всё на питоне. Итак, поставив certbot, я сделал для проверки успешности своих намерений dry-run запуск (так называемый запуск вхолостую, который по факту ничего не делает, а только показывает отчёт), как это предлагалось в документации certbot.
sudo letsencrypt renew --dry-run --agree-tos
Processing /etc/letsencrypt/renewal/spaceismine.org.conf
** DRY RUN: simulating 'letsencrypt renew' close to cert expiry
** (The test certificates below have not been saved.)
Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/spaceismine.org/fullchain.pem (success)
** DRY RUN: simulating 'letsencrypt renew' close to cert expiry
** (The test certificates above have not been saved.)
Success-success, успех-успех! Ну, дальше можно было уже запустить и полноценное обновление сертификата.
sudo letsencrypt renew
Processing /etc/letsencrypt/renewal/spaceismine.org.conf
new certificate deployed without reload, fullchain is /etc/letsencrypt/live/spaceismine.org/fullchain.pem
Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/spaceismine.org/fullchain.pem (success)
Замечательно, он говорит, что всё нам обновил. Делаем релоад нашему nginx.
sudo service nginx reload
И вот всё, сертификат обновлён, всё замечательно. Но, не буду же я раз в 3 месяца заходить обновлять его руками, поэтому я поискал информацию, как лучше всего это прикрутить на cron. Оказывается, ничего особо сложного с этим тоже не было.
sudo crontab -e
и добавляем там
42 0,12 * * * letsencrypt renew --post-hook "service nginx reload"“Зачем делать два раза в день?” спросите вы. Да, это довольно часто, но я столкнулся с мнениями, что в этом нет ничего такого, так как certbot ничего не делает, если сертификат по факту пока обновлять не требуется. Момент необходимости обновления сертификата наступает за 30 дней до его истечения.
Убеждаемся напоследок, что команда cron работает. Многие годы работы с cron научили меня это делать в обязательном порядке.
sudo letsencrypt renew --post-hook "service nginx reload"
Saving debug log to /var/log/letsencrypt/letsencrypt.log
-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/spaceismine.org.conf
-------------------------------------------------------------------------------
Cert not yet due for renewal
The following certs are not due for renewal yet:
/etc/letsencrypt/live/spaceismine.org/fullchain.pem (skipped)
No renewals were attempted.
No hooks were run.
Итак, похоже всё хорошо и всё работает. На этом завершаю свою заметку про автоматическое обновление сертификатов Let’s Ecnrypt.
- Моя прошлогодняя статья про первоначальную настройку Let’s Encrypt
- Сайт certbot
- Сайт проекта Let’s Encrypt
В примере будем использовать сервер с debian 9 и nginx в качестве веб-сервер.
Прежде всего потребуется установить дополнительные пакеты из stretch-backports. Прописываем нужный репозиторий
mcedit /etc/apt/sources.list
Вот и всё
Если вам близки по духу tee и sed, то есть гораздо более короткая инструкция по настройке связки Let’s Encrypt и nginx, при условии корректно настроенного hostname. Только копируй команды и вставляй.
Выпуск и настройка сертификата для панели управления vestacp
Поддержка Let’s Encrypt доступна в VestaCP из коробки.
Для выпуска и установки сертификата вы можете отметить дополнительные опции сразу при добавлении домена в разделе WEB панели VestaCP:
Или отредактировать настройки домена в разделе WEB, выбрав опции поддержки SSL уже после добавления:
Выпуск и автоматическая установка сертификата занимают до 5 минут. После этого данные SSL-сертификата будут доступны также в настройках домена.
Помимо этого, добавляется cron-задание для автоматического обновления сертификатов, истекающих через 30 и менее дней. Проверить это можно в разделе CRON панели VestaCP:
Если нужно добавить поддомен или домен в сертификат
Если вы вдруг забыли указать поддомен www, или вам нужно добавить другой домен или поддомен в сертификат (которых может быть до 100 в одном сертификате), то это легко сделать после получения сертификата. Просто запустите команду еще раз, добавив требуемое имя:
Если нужно получить сертификат для домена без сайта…
Типичный пример — сертификат для выделенных под SMTP или IMAP серверов, на которых вообще нет каких-то сайтов. Либо используйте универсальный переадресатор что выше, либо…
Как это работает
Полное описание процесса доступно по
Важно лишь знать, что для подтверждения владения доменом и успешной генерации сертификата нужно будет иметь доступ к записям DNS или к серверу куда ссылается A-запись, что вполне логично.
Смысл программного набора Automated Certificate Management Environment (ACME) (написан на Python) в том, чтобы автоматизировать генерацию и установку сертификата в Linux-окружении.
Существует неофициальный Windows-клиент с открытыми исходными кодами, который может генерировать и устанавливать сертификаты на Windows IIS и Amazon Web Services, но у нас была задача получить ключи и установить их вручную. Предлагаю любому желающему написать статью по работе с ним.
Немного лирики
Что перво-наперво приходит в голову нормальному человеку, когда ему задают вопрос про замену сертификата? Вариантов два: или — а почему бы вам не купить его? Или — так есть же замечательная артель Let’s Encrypt, которая бесплатно раздаёт сертификаты направо и налево!
Первый вариант был смущённо отвергнут как несостоятельный, ввиду того, что, как было сказано ранее, сервер работал, каши не просил, и объяснять руководству, почему оно должно расстаться с энной суммой вечнозелёных денег желания не было никакого. Второй вариант был просто суперпривлекательным, но на горизонте маячили кое-какие проблемы, которые предстояло объехать: оконность почтовика наводила на грустные размышления о его совместимости со скриптами LetsEncrypt, а получать и устанавливать сертификат вручную каждые три месяца совершенно не хотелось.
Поэтому был выбран второй вариант — только нужно было найти способ автоматизировать процессы получения сертификата и привязки его к почтовику.
Начали мы, естественно, с перекапывания великого и ужасного Интернета в поисках уже готового решения. И, о чудо! Оказалось, что доблестные программисты из Alt-N Technologies уже озаботились этим и выдали на-гора скрипты, делающие всё что нужно! Как говорится — снимаю шляпу!
Но и тут не обошлось без ложки дёгтя: эти скрипты просто так всем и каждому не раздавались, а были включены в состав последних версий MDaemon. Однако наш подопечный сервер имел на борту довольно старую версию MDaemon — 13.6.3. Софт был совершенно легальный, купленный некогда за самые что ни на есть настоящие деньги, работал замечательно и его апгрейд в планы руководства конечно же не входил (см. пункт про покупку сертификата).
Поэтому было принято решение попытаться хирургическим путём пересадить скрипты из новой версии MDaemon в старую и заставить их там заработать. Подумано — сделано: на виртуальную машину была установлена самая свежая на тот момент триальная версия MDaemon и из неё изъята папка LetsEncrypt со всем содержимым. Что теперь делать с этим добром? — читайте ниже.
Обновление/установка сертификата на ос windows xp, vista, 7
Для обновления/установки сертификата на Windows выполните следующие шаги:
Обязательные требования
Как было написано в
, скрипты LetsEncrypt для MDaemon не являются абсолютно универсальными и предполагают выполнение следующих обязательных условий:
Как видим — часть из этих требований исходно не выполнялась, поэтому сначала была выполнена привязка WorldClient к IIS с целью пересадки его на порт 80. Информация о том, как это сделать была получена из
с сайта Alt-N.
Пара слов о «граблях»
Прежде чем приступить к описанию пошаговой инструкции хочу задержать ваше внимание на кое-каких непредвиденных заморочках, осложнивших процесс пересадки скриптов и получения сертификатов.
Во-первых, практически в самом начале скрипта была реализована проверка на то, что параметр ‘EnableWCServer’ в файле ‘Mdaemon.ini’ установлен в ‘Yes’. И если это было не так, то скрипт немедленно завершал свою работу с выдачей сообщения о критической ошибке ‘Error:
WorldClient must be enabled’. Но, как это ни странно, в нашем случае этот параметр был установлен в ‘No’ — несмотря на то, что нами уже была выполнена привязка WorldClient к IIS и WorldClient прекрасно открывался из интернета. Недолго думая, мы отключили эту проверку, закомментарив её в скрипте. Это позволило скрипту продолжить работу.
Подготовим nginx к получению сертификатов
В общем случае для получения сертификата необходимо во всех блоках server добавить следующий блок до других блоков location:
location /.well-known {
root /var/www/html;
}Понятно, что вписывать для каждого сайта такой блок явно — это моветон, потому создадим файл /etc/nginx/acme с содержанием блока выше.
# cat /etc/nginx/acme
location /.well-known {
root /var/www/html;
}Затем для каждого домена и поддомена, для которых нужно получить сертификаты, в блоке server перед всеми блоками location укажем:
include acme;Хосты-редиректоры (например, с голого домена на www) можно пропустить. ACME сервер обязан учитывать стандартную переадресацию. Подробней об этом ниже.
Перезагрузим nginx и проверим что наш тестовый файл виден:
Получаем сертификаты
У Let’s Encrypt есть лимиты на количество обращений за сертификатами, потому сначала попробуем получить необходимый сертификат в режиме для тестов:
Проверим полученный сертификат
Убедимся что полученный сертификат — именно тот, что нам нужен:
Проверка сертификатов
После того как мы получили сертификаты, необходимо их проверить с помощью сервера Zimbra.Для этого создадим папку letsencrypt и скопируем туда полученные сертификаты:mkdir /opt/zimbra/ssl/letsencryptcp /etc/letsencrypt/live/test.my.domain/* /opt/zimbra/ssl/letsencrypt/
Назначим права на эти файлы для пользователя zimbra и проведем верификацию:chown -Rfv zimbra:zimbra /opt/zimbra/ssl/letsencrypt/sudo su – zimbra -c “zmcertmgr verifycrt comm /opt/zimbra/ssl/letsencrypt/privkey.pem /opt/zimbra/ssl/letsencrypt/cert.pem /opt/zimbra/ssl/letsencrypt/zimbra_chain.pem”** Verifying ‘/opt/zimbra/ssl/letsencrypt/cert.pem’ against ‘/opt/zimbra/ssl/letsencrypt/privkey.
pem’Certificate ‘/opt/zimbra/ssl/letsencrypt/cert.pem’ and private key ‘/opt/zimbra/ssl/letsencrypt/privkey.pem’ match.** Verifying ‘/opt/zimbra/ssl/letsencrypt/cert.pem’ against ‘/opt/zimbra/ssl/letsencrypt/zimbra_chain.pem’Valid certificate chain: /opt/zimbra/ssl/letsencrypt/cert.pem: OK
Если проверка завершилась неудачно, то проверяйте как собрался IdenTrust, скорей всего ошибка в нём:** Verifying ‘/opt/zimbra/ssl/letsencrypt/cert.pem’ against ‘/opt/zimbra/ssl/letsencrypt/privkey.pem’Certificate ‘/opt/zimbra/ssl/letsencrypt/cert.pem’ and private key ‘/opt/zimbra/ssl/letsencrypt/privkey.pem’ match.
** Verifying ‘/opt/zimbra/ssl/letsencrypt/cert.pem’ against ‘/opt/zimbra/ssl/letsencrypt/zimbra_chain.pem’ERROR: Unable to validate certificate chain: /opt/zimbra/ssl/letsencrypt/cert.pem: C = US, O = Let’s Encrypt, CN = Let’s Encrypt Authority X3error 2 at 1 depth lookup:unable to get issuer certificate
Продление сертификатов
После того, как все сертификаты получены и настроены сайты и службы их использующие встает вопрос об их продлении. Мы помним, что срок действия сертификата – 90 дней, поэтому если их много и получены они в разное время, то вручную следить за всем этим хозяйством будет весьма и весьма проблематично.
Процесс по шагам
Внимание: эта инструкция учит создавать сертификат в ручном режиме, существуют и более простые способы автоматической генерации и обновления сертификатов. Надеюсь, что скоро их опишут на этом ресурсе.
Установка в jessie
Если у вас еще в ходу актуальный на конец 2021 года Debian stable “jessie”, то всё лишь немного сложнее.
Установка сертификатов
Для установки сертификатов имеет смысл сделать бэкап текущихКопируется файл rivkey.pem в /opt/zimbra/ssl/zimbra/commercial/commercial.key
cp/opt/zimbra/ssl/letsencrypt/privkey.pem /opt/zimbra/ssl/zimbra/commercial/commercial.keychown zimbra:zimbra /opt/zimbra/ssl/zimbra/commercial/commercial.keytar -czf /opt/zimbra/ssl/zimbra-$(date “%d.%m.%y_%H.%M”).tar.gz /opt/zimbra/ssl/zimbra
Останавливаем сервисы Zimbra, и загружаем новые сертификаты и после этого запускаем службы снова:sudo su – zimbra -c “zmproxyctl stop”sudo su – zimbra -c “zmmailboxdctl stop”sudo su – zimbra -c “zmcertmgr deploycrt comm /opt/zimbra/ssl/letsencrypt/cert.pem /opt/zimbra/ssl/letsencrypt/zimbra_chain.pem”sudo su – zimbra -c “zmcontrol restart”
Часть 2: создание в iis сайта для доступа к серверу worldclient
Примечание 1:
если у вас используется встроенный в MDaemon сервер WorldClient и он уже монопольно сидит на порту 80, то можете смело пропустить эту часть и перейти сразу к части 3.
Примечание 2: ‘Host name’ сайта должно быть таким-же, как полное доменное имя хоста MDaemon, по которому он доступен из интернета.
Часть 5: удаление всех следов «тестовой» жизнедеятельности
Если этого не сделать, то скрипт ещё пару месяцев будет продолжать выдавать нам «фальшивый» сертификат, несмотря на то, что мы внесли в скрипт нужные изменения.
Часть 7: первый «боевой» запуск
Выполняем старт скрипта вручную:
- Выделяем только-что созданную задачу в списке.
- Нажимаем ‘Run’ в правой панели Actions’. Никакого окна при этом не откроется.
- Время от времени рефрешим список задач — чтобы видеть изменения в поле ‘Status’: ‘Status’ должен смениться на ‘Run’. Рефрешим список, пока ‘Status’ снова не станет ‘Ready’.
- Смотрим результат выполнения скрипта в лог-файле ‘MDaemonLogsLetsEncrypt.log’.
Часть последняя — заключительная
В заключение хочу сказать, что во время написания статьи у меня уже не было доступа к боевому серверу, поэтому все скриншоты делались с виртуальной машины, на которую была установлена ещё более старая версия MDaemon — 13.0.4 — из-за чего внешний вид окон может отличаться от других версий.
Ну вот и всё. Всё что знал — рассказал. Поздравляю всех с наступающим Новым Годом! Здоровья вам и удачи!
Шаг 2. остановите службу прокси zimbra
Нам нужно остановить сервисы службы jetty или nginx, прежде чем мы сможем настроить сервер на использование SSL-сертификата Let Encrypt.
$ sudo su - zimbra -c "zmproxyctl stop"
Stopping proxy...done.
$ sudo su - zimbra -c "zmmailboxdctl stop"
Stopping mailboxd...done.Шаг 3: получим ssl-сертификат lets encrypt
Когда службы Zimbra proxy и mailboxd будут остановлены, мы можем перейти к запросу Let Encrypt в автоматическом режиме.
Убедитесь, что вы передаете все имена хостов, используемые вашим почтовым сервером.
