Wildcard SSL сертификат

Понадобилось сгенерировать wildcard SSL сертификат и раскладывать его по пространствам имён в Kubernetes кластере. Этот сертификат будет использоваться в тестах которые выполняются для набора приложений на каждый запрос на слияние.

В cert-manager настроен ClusterIssuer LE с валидацией через DNS01. Выпуск wildcard сертификата у Let's Encrypt поддерживается только через DNS валидацию и протокол ACMEv2. В примере использован сервис Cloud DNS от Google Cloud Platform.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-production
spec:
  acme:
    email: certificates@example.com
    privateKeySecretRef:
      name: letsencrypt-production
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
    - dns01:
        cloudDNS:
          project: GCP_PROJECT_ID

Манифест для wildcard сертификата (сам сертификат и ключ будут созданы в пространстве имён cert-manager)

Собрал пакет для acme.sh версии 2.8.5

Версия 2.8.5 вышла еще в январе, но обновить пакет в моем репозитарии руки дошли только вчера. Последняя версия добавлена в репозитарий только для Debian Buster и Debian Sid, но пакет acme.sh_2.8.5-1_all.deb должен устанавливаться на другие версии Debian/Ubuntu без проблем.

Из заметных изменений:

• Добавил страницу man для acme.sh
• Исправил предупреждения lintian
• Поменял структуру для deploy/dnsapi/notify хуков - есть подозрение что в предыдущих релизах они не работали, но протестировать их мне не довелось

Собрал acme.sh для Debian

Какое-то время назад крон, который обновляет сертификаты Let's Encrypt, стал выдавать ошибку вида:

Renew: 'www.tataranovich.com'
Multi domain='DNS:tataranovich.com'
Getting domain auth token for each domain
Getting webroot for domain='www.tataranovich.com'
Getting new-authz for domain='www.tataranovich.com'
The new-authz request is ok.
new-authz error: {"type":"urn:acme:error:badNonce","detail":"JWS has no anti-replay nonce","status": 400}
Please check log file for more details: le-issue.log
Error renew www.tataranovich.com.

Сегодня занялся этой проблемой вплотную. Поиск вывел на описание ошибки urn:acme:error:badNonce (JWS has no anti-replay nonce). Для работы с сертификатами LE я использую acme.sh. И чтобы решить проблему достаточно обновить версию.

Собрал Debian пакет для acme.sh 2.8.3 и залил его в мой репозитарий для Debian Stretch и Debian Buster.

Описание релиза 2.8.3 на GitHub:

Letsencrypt CA recent changed the CDN provider, which resulted in hanging issues. Any downstream package should update. This is important.

После установки новой версии сертификаты обновились без проблем.

WordPress и SSL в ISPmanager

Пару лет назад я взялся поддерживать сайт товарищества собственников дома. Сайт работает на WordPress и хостится на одном из хостингов в РБ. Сделано это чтобы у бухгалтера не было возни с зарубежными хостингами и кроме того непонятно насколько президентский указ №60 относится к товариществу собственников.

На момент создания сайта товарищества Let's Encrypt еще не успел набрать популярность, а платить за воздух покупать платный SSL сертификат не было никакого желания. Теперь хостинг предлагает бесплатные SSL сертификаты от Let's Encrypt, но эта опция доступна только для новых тарифных планов. Помимо бесплатного SSL обещают поддержку PHP 7.2.x (в текущем тарифном плане доступен максимум PHP 7.0.x). Заодно пришло уведомление о скором истечении оплаченного периода и я решил потратить немного времени и попробовать перенести сайт на новый тариф и заодно включить поддержку SSL.

Рекомендуемые настройки SSL от Mozilla

Нашел хороший генератор настроек SSL от Mozilla. В их wiki есть статья где расписаны три рекомендуемых профиля и возможные ограничения, связанные с их использованием.

Ну и еще раз продублирую ссылку на SSL сканер от Qualys.

Настройка mod_ssl в apache 2.2.x

Поправил дефолтные настройки mod_ssl для Apache 2.2.x

<IfModule mod_ssl.c>
  SSLRandomSeed startup builtin
  SSLRandomSeed startup file:/dev/urandom 512
  SSLRandomSeed connect builtin
  SSLRandomSeed connect file:/dev/urandom 512
  AddType application/x-x509-ca-cert .crt
  AddType application/x-pkcs7-crl    .crl
  SSLPassPhraseDialog  builtin
  SSLSessionCache        shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)
  SSLSessionCacheTimeout  300
  SSLMutex  file:${APACHE_RUN_DIR}/ssl_mutex
  SSLCipherSuite kEECDH+AESGCM+AES128:kEECDH+AES128:kRSA+AESGCM+AES128:kRSA+AES128:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2
  SSLHonorCipherOrder on
  SSLProtocol All -SSLv2 -SSLv3
</IfModule>

Если прописать такие настройки в /etc/apache2/mods-available/ssl.conf, то SSL Server Test не выдает дополнительных рекомендаций.

Тестирование SSL/TLS

В процессе фикса Logjam потребовался инструмент для оценки последствий примененного изменения. Нашел сканер от ssllabs. Этот сканер позволяет оценить число клиентов, которые больше не смогут подключиться к серверу. В моем случае это были IE6/WinXP и IE8/WinXP.

Три новые уязвимости в OpenSSL

Опубликовали репорт на три новые уязвимости в OpenSSL (CVE-2014-3566, CVE-2014-3567, CVE-2014-3068). В качестве решения предлагается обновить OpenSSL до следующих версий:

OpenSSL 1.0.1 users should upgrade to 1.0.1j
OpenSSL 1.0.0 users should upgrade to 1.0.0o
OpenSSL 0.9.8 users should upgrade to 0.9.8zc

В репозитариях Debian и CentOS обновление пока не замечено. Для защиты от CVE-2014-3566 отключил поддержку SSLv3 на серверах.

Добавление корневого сертификата локального CA в системный ca-certificates.crt и Java keystore

При попытке подключиться в JXplorer к LDAP серверу с использованием SSL выдало предупреждение о неизвестном сертификате.

Вариант "This Session Only" решает проблему, но является временным. Попытка выбрать вариант "Always" заканчивается ошибкой, поскольку нет прав на запись в системное хранилище (/etc/ssl/certs/java/cacerts).

В Debian установка корневых сертификатов автоматизирована - нужно установить пакет ca-certificates, скопировать нужный сертификат в директорию /usr/local/share/ca-certificates и выполнить команду update-ca-certificates.

# aptitude install ca-certificates
# install -m 0644 /tmp/Corp-CA.crt /usr/local/share/ca-certificates
# update-ca-certificates

При этом содержимое сертификата Corp-CA.crt будет добавлено в бандл /etc/ssl/certs/ca-certificates.crt (используется по-умолчанию приложениями в системе) и при необходимости в дополнительные хранилища, подключенные через хуки /etc/ca-certificates/update.d. Поскольку у меня установлена java, то добавление сертификата в хранилище java произойдет автоматически при выполнении хука /etc/ca-certificates/update.d/jks-keystore.

Если вы хотите добавить сертификат руками, то это можно сделать так:

$ sudo keytool -keystore /etc/ssl/certs/java/cacerts -import -trustcacerts -alias "Corp CA" -file /tmp/Corp-CA.crt

В процессе выполнения спросит пароль от keystore - если вы ничего не меняли, то пароль по-умолчанию "changeit". Теперь проверим, что наш сертификат добавился

keytool -keystore /etc/ssl/certs/java/cacerts -list -alias 'Corp CA'
Corp CA, 29.05.2014, trustedCertEntry, 
Certificate fingerprint (SHA1): 15:2C:D3:50:20:69:43:2D:C7:C1:B7:06:6A:23:38:07:63:F3:EF:22

Теперь jxplorer подключается без лишних вопросов.

139905006626448:error:0906D064:PEM routines:PEM_read_bio:bad base64 decode:pem_lib.c:818:

В процессе устранения CVE-2014-0160 дошел до обновления всех сертификатов на серверах. Поскольку уязвимость создает вероятность получения секретного ключа, то нужно сгенерировать сертификат заново.

$ openssl genrsa -out /etc/ssl/private/example.com.key 2048
$ chmod 0400 /etc/ssl/private/example.com.key
$ openssl req -new -out /etc/ssl/certs/example.com.csr -key /etc/ssl/private/example.com.key

Полученный файл example.com.csr нужно подписать у удостоверяющего центра. Мы пользуемся Thawte через посредника и в ответ на повторный выпуск сертификата пришел zip архив

$ unzip -l reissue.zip
Archive:  reissue.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
     1744  2014-04-09 09:56   ServerCertificate.cer
     4815  2014-04-09 09:56   PKCS7.p7b
     1642  2014-04-09 09:56   CACertificate-1.cer
     1540  2014-04-09 09:56   CACertificate-2.cer
---------                     -------
     9741                     4 files

Файлы с расширением CER это сертификат в формате PEM. Перед установкой нового сертификата в веб-сервер проверяю его информацию

$ mkdir ssl-tmp
$ cd ssl-tmp
$ unzip ../reissue.zip
$ openssl x509 -in ServerCertificate.cer -text -noout
unable to load certificate
139905006626448:error:0906D064:PEM routines:PEM_read_bio:bad base64 decode:pem_lib.c:818:

Облом. OpenSSL отказывается читать сертификат, ссылаясь на неверное base64 кодирование. Открываю сертификат в текстовом редакторе и смотрю его глазами. В теле base64 есть пробелы! А ведь пробелов быть не должно... Попробовал сравнить содержимое с предыдущим сертификатом и нашел, что возможно по ошибке "+" заменился на " ". В качестве проверки делаю замену всех пробелов на "+" между строками "-----BEGIN CERTIFICATE-----" и "-----END CERTIFICATE-----".

После замены снова проверяю сертификат

$ openssl x509 -in ServerCertificate.cer -text -noout

В этот раз проверка прошла успешно, повторяю действия для CACertificate-1.cer и CACertificate-2.cer. И проверяю их аналогично. В конце останется только установить новый сертификат на сервере.

Workflow: SSL сертификаты

Одна из рутинных операций, с которыми приходится сталкиваться системному администратору - управление SSL сертификатами. Я постараюсь собрать на одной странице справочное руководство, которое поможет управлять жизненным циклом сертификата. Для наглядности процесса я буду описывать процедуру в контексте WEB сервера (в остальных случаях многое совпадает, хотя есть и различия).

Для себя я выделяю несколько этапов в жизненном цикле SSL сертификата:

• создание SSL сертификата
• установка SSL сертификата
• мониторинг валидности и срока окончания SSL сертификата

TinyCA: Проверка срока действия сертификатов

Для управления сертификатами использую TinyCA. Недостаток этого решения в том, что об окончании срока действия сертификата узнаешь только тогда, когда он уже окончился.

Чтобы узнавать об этом заранее, я решил набросать небольшой скрипт, который проходится по хранилищу сертификатов и проверяет их "годность" (TinyCA хранит сертификаты в каталоге ~/.TinyCA/CAName/certs).

Выходит, что для проверки достаточно пройтись по всем ~/.TinyCA/CAName/certs/*.pem файлам. Нагуглил скрипт на perl, который проверяет срок действия сертификата. Скрипт завершается с кодом 2, если сертификат просрочен, с кодом 1, если истечет в течении двух недель и с нулевым, если с сертификатом все в порядке.

Далее дописал обвязку для крона, который проверяет сертификаты из ~/.TinyCA/CAName/certs

check-certificate-expire - проверка единичного сертификата

#!/bin/sh

openssl_get_CN_from_file() {
  if [ ! -f "$1" ]; then
    echo "Unable to find file: $1"
    return 1
  fi

  X509_CN=`openssl x509 -in "$1" -noout -subject | perl -pi -e 's/^.*\/?CN=([^\/]*).*$/\1/'`
  echo $X509_CN
}

if [ ! -f "$1" ]; then
  echo "Unable to find file: $1"
  exit 1
fi

check-expire -f /usr/local/etc/check-expire.cfg openssl_x509 -in "$1"

case $? in
  1)
    X509_CN=`openssl_get_CN_from_file "$1"`
    if [ ! -z "$X509_CN" ]; then
      echo "$X509_CN: certificate expires soon"
    else
      echo "$1: certificate expires soon"
    fi
    ;;
  2)
  X509_CN=`openssl_get_CN_from_file "$1"`
  if [ ! -z "$X509_CN" ]; then
    echo "$X509_CN: certificate expired!"
  else
    echo "$1: certificate expired!"
  fi
  ;;
esac

check_tinyca_certs - проверка сертификатов из директории

#!/bin/sh

if [ ! -d "$1" ]; then
  echo "Unable to find directory: $1"
  exit 1
fi

for sslcert in "$1"/*.pem
do
  if [ -f "$sslcert" ]; then
    check-certificate-expire "$sslcert"
  else
    echo "File $sslcert not found"
  fi
done

Конфиг для скрипта check-expire

<class default>
        <expired>
                exit_value 2
        </expired>

        <window>
                inside 2w
                exit_value 1
        </window>
</class>

Disable SSLv2 and weak ciphers

Comprehensive guide how to disable SSLv2 and weak ciphers. As a quick reference for Apache:

<IfModule mod_ssl.c>
    SSLProtocol -ALL +SSLv3 +TLSv1
    SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM
</IfModule>

To test new settings:

$ openssl s_client -ssl2 -connect servername:443
CONNECTED(00000003)
32386:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:428:

$ openssl s_client  -connect servername:443 -cipher LOW:EXP

CONNECTED(00000003)
32391:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:602:

Проверка сертификата FTP сервера.

Довелось проверить валидность сертификата на FTP сервере. Раньше такого не делал, так что полез курить ман по openssl. Получись так:

openssl s_client -connect ftp.site.com:21 -starttls ftp

Вообще отличная дока по практическому применению openssl есть тут

Проблемы с сертификатами GoDaddy на Mac Safari

Недавно прислали по работе - под маковским safari не проверяет валидность сертификатов от GoDaddy, выкидывает ошибку вида



Чтобы это исправить, достаточно прописать SSLCertificateChainFile /path/to/gd_bundle.crt в конфиге сервера.

Проверка сертификата:

openssl verify -CAfile gd_bundle.crt -purpose sslserver site.crt

Неплохой Online SSL checker