Nginx upstream ssl certificate verify error - Исправление ошибок и поиск оптимальных решений проблем

Symptom:

We hit various SSL handshake, connection, verification errors when we config upstream SSL in nginx following the guide

*1 upstream SSL certificate does not match «loginapp» while SSL handshaking to upstream, client: 110.126.174.93, server: test.com, request: «GET /auth/ HTTP/1.1», upstream: «https://198.19.163.33:5555/», host: «platform.nw-dev.kubernetes.cba», referrer: «https://platform.nw-dev.kubernetes.cba/»

2021/12/10 01:06:27 [error] 7#7: *1 upstream SSL certificate verify error: (20:unable to get local issuer certificate) while SSL handshaking to upstream, client: 110.126.174.93, server: test.com, request: «GET /auth/ HTTP/1.1», upstream: «https://198.19.163.33:5555/», host: «test.com», ref

Diagnose:

It turns out the upstream in nginx config has the same DOMAIN requirement of HTTPS. For example:

upstream myapp{
server myapp.svc.test.com:556;
}

location /myapp{
   proxy_pass https://myapp;
   proxy_ssl_trusted_certificate /etc/nginx/rootca/ClusterCA.pem;
   proxy_ssl_verify on;
   proxy_ssl_session_reuse on;
   }

The TLS certificate from the myapp.svc.test.com would need to have COMMON or DNS alias myapp in it, otherwise, the SSL handshake will fail. In other words, the upstream «myapp» needs to match the the TLS certificate CN in the myapp.svc.test.com. The tricky part is that the CN in the TLS certficate needs to match upstream, not the «myapp.svc.test.com» ie below will work as long as TLS in random.example.com has «myapp1.svc.test.com» in it.

upstream myapp1.svc.test.com {
server random.example.com:556;
}

To add another layer of security, to prevent man-in-the middle attack which host fake HTTPS for hacking purpose, we can set certain CA we trust for the upsteam server

Set proxy_ssl_verify is on, the upsteam TLS certificate needs to be signed by the certain CA nginx can trust which is configured at proxy_ssl_trusted_certificate, otherwise, SSL verifies will fail.

To further harden security, we can add mTLS,example like below refer what is mTLS here

location /myapp{
       proxy_pass https://backend.example.com;
       proxy_ssl_certificate /etc/nginx/client.pem;
       proxy_ssl_certificate_key /etc/nginx/client.key;
       proxy_ssl_trusted_certificate /etc/nginx/trusted_ca_cert.crt;
       proxy_ssl_verify on;
       proxy_ssl_session_reuse on;
   }

Refer more detailed info via nginx bug doc

Источник

I’m running

nginx -V
nginx version: nginx/1.19.0 (pgnd Build)
built with OpenSSL 1.1.1g 21 Apr 2020
TLS SNI support enabled
…

It serves as front-end SSL termination, site host, and reverse-proxy to backend apps.

I’m trying to get a backend app to proxy_ssl_verify the proxy connection to it.

I have two self-signed certs:

One for «TLS Web Client Authentication, E-mail Protection»

openssl x509 -in test.example.com.client.crt -text | egrep «Subject.*CN|DNS|TLS»
Subject: C = US, ST = NY, L = New_York, O = example2.com, OU = myCA, CN = test.example.com, emailAddress = ssl@example2.com
TLS Web Client Authentication, E-mail Protection
DNS:test.example.com, DNS:www.test.example.com, DNS:localhost

and the other, for «TLS Web Server Authentication»

openssl x509 -in test.example.com.server.crt -text | egrep «Subject.*CN|DNS|TLS»
Subject: C = US, ST = NY, L = New_York, O = example2.com, OU = myCA, CN = test.example.com, emailAddress = ssl@example2.com
TLS Web Server Authentication
DNS:test.example.com, DNS:www.test.example.com, DNS:localhost

The certs ‘match’ CN & SAN, differing in «X509v3 Extended Key Usage».

Both are verified «OK» with my local CA cert

openssl verify -CAfile myCA.crt.pem test.example.com.server.crt
test.example.com.server.crt: OK

openssl verify -CAfile /myCA.crt.pem test.example.com.client.crt
test.example.com.client.crt: OK

My main nginx config includes,

upstream test.example.com {
server test.example.com:11111;
}
server {

listen 10.10.10.1:443 ssl http2;
server_name example.com;
…

ssl_verify_client on;
ssl_client_certificate «/etc/ssl/nginx/myCA.crt»;
ssl_verify_depth 2;
ssl_certificate «/etc/ssl/nginx/example.com.server.crt»;
ssl_certificate_key «/etc/ssl/nginx/example.com.server.key»;
ssl_trusted_certificate «/etc/ssl/nginx/myCA.crt»;

location /app1 {
proxy_pass https://test.example.com;
proxy_ssl_certificate «/etc/ssl/nginx/test.example.com.client.crt»;
proxy_ssl_certificate_key «/etc/ssl/nginx/test.example.com.client.key»;
proxy_ssl_trusted_certificate «/etc/ssl/nginx/myCA.crt»;
proxy_ssl_verify on;
proxy_ssl_verify_depth 2;
include includes/reverse-proxy.inc;
}
}

and the upstream config,

server {
listen 127.0.0.1:11111 ssl http2;
server_name test.example.com;

root /data/webapps/demo_app/;
index index.php;
expires -1;

ssl_certificate «/etc/ssl/nginx/test.example.com.server.crt»;
ssl_certificate_key «/etc/ssl/nginx/test.example.com.server.key»;

ssl_client_certificate «/etc/ssl/nginx/myCA.crt»;
ssl_verify_client optional;
ssl_verify_depth 2;

location ~ .php {
try_files $uri =404;
fastcgi_pass phpfpm;
fastcgi_index index.php;
fastcgi_param PATH_INFO $fastcgi_script_name;
include fastcgi_params;
}

}

access to

https://example.com/app1

responds,

502 Bad Gateway

logs, show an SSL handshake fail

…
2020/05/29 19:00:06 [debug] 29419#29419: *7 SSL: TLSv1.3, cipher: «TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD»
2020/05/29 19:00:06 [debug] 29419#29419: *7 http upstream ssl handshake: «/app1/?»
2020/05/29 19:00:06 [debug] 29419#29419: *7 X509_check_host(): no match
2020/05/29 19:00:06 [error] 29419#29419: *7 upstream SSL certificate does not match «test.example.com» while SSL handshaking to upstream, client: 10.10.10.73, server: example.com, request: «GET /app1/ HTTP/2.0», upstream: «https://127.0.0.1:11111/app1/», host: «example.com»
2020/05/29 19:00:06 [debug] 29419#29419: *7 http next upstream, 2
…

If I toggle

— ssl_verify_client on;
+ ssl_verify_client off;

then I’m able to connect to the backend site, as expected.

What exactly is NOT matching in the handshake? CN & SAN do …

&/or, is there a config problem above?

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Источник

When proxying a request to an underlying server, it is necessary to validate its SSL certificate. For example, if we have a process running on https://localhost:5001, we can configure Nginx to validate the certificate used by localhost:5001. But if we miss one step, we face the common error 502 Bad Gateway returned by Nginx. Today we will see two scenarios where we can face the error and how to fix them:

Setup SSL verification
Scenario 1: self-signed certificate
Scenario 2: upstream server

1. Setup SSL verification

We can tell Nginx to verify the underlying SSL by adding the following directives, either on server or location level:

server {
  // ... more config
  
  proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
  proxy_ssl_verify on;
  proxy_ssl_session_reuse on;

  location / {
    proxy_pass https://localhost:5001/;
  }
}

proxy_ssl_trusted_certificate indicates to Nginx the location of the trusted CA certificates.
proxy_ssl_verify on specifies that the proxied ssl should be verified.

2. Scenario 1: self-signed certificate

If localhost certificate is already trusted or signed by a trusted root CA, the proxied request will be successful. But if it isn’t, Nginx will return 502 Bad Gateway.

For example, if we have created a self-signed certificate, we will need to add our certificate to the trusted ones. To do that, we can use the update-ca-certificates command. We start first by copying our certificate which we used for localhost to /usr/local/share/ca-certificates/localhost/localhost.crt which is the location which will be scanned to add user certificates to the trusted CA certs.

sudo cp ~/localhost.crt /usr/local/share/ca-certificates/localhost/
sudo update-ca-certificates

Once updated, we should now be able to access tne site.

3. Scenario 2: upstream server

Continuing on the self-signed certificate, if we created with a Subject Alternative Name of DNS Name=localhost, the certificate is viewed as valid by Nginx if we proxy to localhost. But if we create an upstream server, for example:

upstream test {
   server localhost:5001;
}

server {
  // ... more config
  
  proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
  proxy_ssl_verify on;
  proxy_ssl_session_reuse on;

  location / {
    proxy_pass https://test/;
  }
}

We would face again the same 502 Bad Gateway issue. If we check the Nginx error log, we will see the following error:

[error] 504#504: *9 upstream SSL certificate does not match "test" while SSL handshaking to upstream, client: ::1, server: , request: "GET /api/values/ HTTP/1.1", upstream: "https://127.0.0.1:5001/api/values/", host: "localhost"

This is due to the fact that the name used to be verified against the SSL certificate name is the $proxy_host by default, here test. To override it, we can use proxy_ssl_name.

upstream test {
   server localhost:5001;
}

server {
  // ... more config
  
  proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
  proxy_ssl_verify on;
  proxy_ssl_session_reuse on;
  proxy_ssl_name localhost;

  location / {
    proxy_pass https://test/;
  }
}

We should now be able to access the site again. We wouldn’t have to do this if the upstream name matched the common name used in the SSL certificate.

Hope this was helpful, see you next time!

Источник

Содержание

nginx проблемы с авторизацией по сертификату
Может кому пригодится
Модуль ngx_http_ssl_module
Пример конфигурации
Директивы
Обработка ошибок
Встроенные переменные

nginx проблемы с авторизацией по сертификату

nginx 1.6.2, самоподписанные сертификаты сервера и клиента, openssl проверку проходят:

А при запросе nginx отвечает ошибкой 400 The SSL certificate error

В логах сервера:

Я правильно понимаю, что серверу не нравится то, что сертификат самоподписанный? Как разрешить?

Вот это результата не дало:

Работает с ssl_verify_client optional_no_ca; , но результат не тот, что хотелось бы $ssl_client_verify=’FAILED’

Есть возможность получить сертификат от LetsEncrypt?

Перепроверь сертификаты: клиентский должен быть подписан ключом CA:

Если считаешь, что всё ок — покажи их.

Раньше не мог ответить. Решил проблему еще в пятницу, пересоздав сертифкаты.

Может кому пригодится

До этого момента подразумевается, что у вас уже есть nginx с fast cgi и mod ssl и вам нужно исправить (400 Bad Request No required SSL certificate was sent) и ошибки подобные (error 18 at 0 depth lookup:self signed certificate OK ) и ошибок с не достоверным сертификатом без доступа к ресурсу (NET::ERR_CERT_INVALID).

Источник

Модуль ngx_http_ssl_module

Модуль ngx_http_ssl_module обеспечивает работу по протоколу HTTPS.

По умолчанию этот модуль не собирается, его сборку необходимо разрешить с помощью конфигурационного параметра —with-http_ssl_module .

Для сборки и работы этого модуля нужна библиотека OpenSSL.

Пример конфигурации

Для уменьшения загрузки процессора рекомендуется

установить число рабочих процессов равным числу процессоров,
разрешить keep-alive соединения,
включить разделяемый кэш сессий,
выключить встроенный кэш сессий
и, возможно, увеличить время жизни сессии (по умолчанию 5 минут):

Директивы

Умолчание:
Синтаксис:	ssl on \| off ;
Контекст:	http , server

Эта директива устарела в версии 1.15.0. Вместо неё следует использовать параметр ssl директивы listen.

Умолчание:
Синтаксис:	ssl_buffer_size size ;
Контекст:	http , server

Эта директива появилась в версии 1.5.9.

Задаёт размер буфера, используемого при отправке данных.

По умолчанию размер буфера равен 16k, что соответствует минимальным накладным расходам при передаче больших ответов. С целью минимизации времени получения начала ответа (Time To First Byte) может быть полезно использовать меньшие значения, например:

Синтаксис:	ssl_certificate файл ;
Умолчание:	—
Контекст:	http , server

Указывает файл с сертификатом в формате PEM для данного виртуального сервера. Если вместе с основным сертификатом нужно указать промежуточные, то они должны находиться в этом же файле в следующем порядке: сначала основной сертификат, а затем промежуточные. В этом же файле может находиться секретный ключ в формате PEM.

Начиная с версии 1.11.0 эта директива может быть указана несколько раз для загрузки сертификатов разных типов, например RSA и ECDSA:

Возможность задавать отдельные цепочки сертификатов для разных сертификатов есть только в OpenSSL 1.0.2 и выше. Для более старых версий следует указывать только одну цепочку сертификатов.

Начиная с версии 1.15.9 в имени файла можно использовать переменные при использовании OpenSSL 1.0.2 и выше:

Однако нужно учитывать, что при использовании переменных сертификат загружается при каждой операции SSL handshake, что может отрицательно влиять на производительность.

Вместо файла можно указать значение data : $переменная (1.15.10), при котором сертификат загружается из переменной без использования промежуточных файлов. При этом следует учитывать, что ненадлежащее использование подобного синтаксиса может быть небезопасно, например данные секретного ключа могут попасть в лог ошибок.

Нужно иметь в виду, что из-за ограничения протокола HTTPS для максимальной совместимости виртуальные серверы должны слушать на разных IP-адресах.

Синтаксис:	ssl_certificate_key файл ;
Умолчание:	—
Контекст:	http , server

Указывает файл с секретным ключом в формате PEM для данного виртуального сервера.

Вместо файла можно указать значение engine : имя : id (1.7.9), которое загружает ключ с указанным id из OpenSSL engine с заданным именем .

Вместо файла можно указать значение data : $переменная (1.15.10), при котором секретный ключ загружается из переменной без использования промежуточных файлов. При этом следует учитывать, что ненадлежащее использование подобного синтаксиса может быть небезопасно, например данные секретного ключа могут попасть в лог ошибок.

Начиная с версии 1.15.9 в имени файла можно использовать переменные при использовании OpenSSL 1.0.2 и выше.

Умолчание:
Синтаксис:	ssl_ciphers шифры ;
Контекст:	http , server

Описывает разрешённые шифры. Шифры задаются в формате, поддерживаемом библиотекой OpenSSL, например:

Полный список можно посмотреть с помощью команды “ openssl ciphers ”.

В предыдущих версиях nginx по умолчанию использовались другие шифры.

Синтаксис:	ssl_client_certificate файл ;
Умолчание:	—
Контекст:	http , server

Указывает файл с доверенными сертификатами CA в формате PEM, которые используются для проверки клиентских сертификатов и ответов OCSP, если включён ssl_stapling.

Список сертификатов будет отправляться клиентам. Если это нежелательно, можно воспользоваться директивой ssl_trusted_certificate.

Синтаксис:	ssl_conf_command имя значение ;
Умолчание:	—
Контекст:	http , server

Эта директива появилась в версии 1.19.4.

Задаёт произвольные конфигурационные команды OpenSSL.

Директива поддерживается при использовании OpenSSL 1.0.2 и выше.

На одном уровне может быть указано несколько директив ssl_conf_command :

Директивы наследуются с предыдущего уровня конфигурации при условии, что на данном уровне не описаны свои директивы ssl_conf_command .

Следует учитывать, что изменение настроек OpenSSL напрямую может привести к неожиданному поведению.

Синтаксис:	ssl_crl файл ;
Умолчание:	—
Контекст:	http , server

Эта директива появилась в версии 0.8.7.

Указывает файл с отозванными сертификатами (CRL) в формате PEM, используемыми для проверки клиентских сертификатов.

Синтаксис:	ssl_dhparam файл ;
Умолчание:	—
Контекст:	http , server

Эта директива появилась в версии 0.7.2.

Указывает файл с параметрами для DHE-шифров.

По умолчанию параметры не заданы, и соответственно DHE-шифры не будут использоваться.

До версии 1.11.0 по умолчанию использовались встроенные параметры.

Умолчание:
Синтаксис:	ssl_early_data on \| off ;
Контекст:	http , server

Эта директива появилась в версии 1.15.3.

Разрешает или запрещает TLS 1.3 early data.

Запросы, отправленные внутри early data, могут быть подвержены атакам повторного воспроизведения (replay). Для защиты от подобных атак на уровне приложения необходимо использовать переменную $ssl_early_data.

Директива поддерживается при использовании OpenSSL 1.1.1 и выше (1.15.4) или BoringSSL.

Умолчание:
Синтаксис:	ssl_ecdh_curve кривая ;
Контекст:	http , server

Эта директива появилась в версиях 1.1.0 и 1.0.6.

Задаёт кривую для ECDHE-шифров.

При использовании OpenSSL 1.0.2 и выше можно указывать несколько кривых (1.11.0), например:

Специальное значение auto (1.11.0) соответствует встроенному в библиотеку OpenSSL списку кривых для OpenSSL 1.0.2 и выше, или prime256v1 для более старых версий.

До версии 1.11.0 по умолчанию использовалась кривая prime256v1 .

При использовании OpenSSL 1.0.2 и выше директива задаёт список кривых, поддерживаемых сервером. Поэтому для работы ECDSA-сертификатов важно, чтобы список включал кривые, используемые в сертификатах.

Умолчание:
Синтаксис:	ssl_ocsp on \| off \| leaf ;
Контекст:	http , server

Эта директива появилась в версии 1.19.0.

Включает проверку OCSP для цепочки клиентских сертификатов. Параметр leaf включает проверку только клиентского сертификата.

Для работы проверки OCSP необходимо дополнительно установить значение директивы ssl_verify_client в on или optional .

Для преобразования имени хоста OCSP responder’а в адрес необходимо дополнительно задать директиву resolver.

Умолчание:
Синтаксис:	ssl_ocsp_cache off \| [ shared : имя : размер ];
Контекст:	http , server

Эта директива появилась в версии 1.19.0.

Задаёт имя и размер кэша, который хранит статус клиентских сертификатов для проверки OCSP-ответов. Кэш разделяется между всеми рабочими процессами. Кэш с одинаковым названием может использоваться в нескольких виртуальных серверах.

Параметр off запрещает использование кэша.

Синтаксис:	ssl_ocsp_responder url ;
Умолчание:	—
Контекст:	http , server

Эта директива появилась в версии 1.19.0.

Переопределяет URL OCSP responder’а, указанный в расширении сертификата “Authority Information Access” для проверки клиентских сертификатов.

Поддерживаются только “ http:// ” OCSP responder’ы:

Синтаксис:	ssl_password_file файл ;
Умолчание:	—
Контекст:	http , server

Эта директива появилась в версии 1.7.3.

Задаёт файл с паролями от секретных ключей, где каждый пароль указан на отдельной строке. Пароли применяются по очереди в момент загрузки ключа.

Умолчание:
Синтаксис:	ssl_prefer_server_ciphers on \| off ;
Контекст:	http , server

Указывает, чтобы при использовании протоколов SSLv3 и TLS серверные шифры были более приоритетны, чем клиентские.

Умолчание:
Синтаксис:	ssl_protocols [ SSLv2 ] [ SSLv3 ] [ TLSv1 ] [ TLSv1.1 ] [ TLSv1.2 ] [ TLSv1.3 ];
Контекст:	http , server

Разрешает указанные протоколы.

Параметры TLSv1.1 и TLSv1.2 (1.1.13, 1.0.12) работают только при использовании OpenSSL 1.0.1 и выше.

Параметр TLSv1.3 (1.13.0) работает только при использовании OpenSSL 1.1.1 и выше.

Умолчание:
Синтаксис:	ssl_reject_handshake on \| off ;
Контекст:	http , server

Эта директива появилась в версии 1.19.4.

Если разрешено, то операции SSL handshake в блоке server будут отклонены.

Например в этой конфигурации отклоняются все операции SSL handshake с именем сервера, отличным от example.com :

Умолчание:
Синтаксис:	ssl_session_cache off \| none \| [ builtin [: размер ]] [ shared : название : размер ];
Контекст:	http , server

Задаёт тип и размеры кэшей для хранения параметров сессий. Тип кэша может быть следующим:

off жёсткое запрещение использования кэша сессий: nginx явно сообщает клиенту, что сессии не могут использоваться повторно. none мягкое запрещение использования кэша сессий: nginx сообщает клиенту, что сессии могут использоваться повторно, но на самом деле не хранит параметры сессии в кэше. builtin встроенный в OpenSSL кэш, используется в рамках только одного рабочего процесса. Размер кэша задаётся в сессиях. Если размер не задан, то он равен 20480 сессиям. Использование встроенного кэша может вести к фрагментации памяти. shared кэш, разделяемый между всеми рабочими процессами. Размер кэша задаётся в байтах, в 1 мегабайт может поместиться около 4000 сессий. У каждого разделяемого кэша должно быть произвольное название. Кэш с одинаковым названием может использоваться в нескольких виртуальных серверах. Также он используется для автоматического создания, хранения и периодического обновления ключей TLS session tickets (1.23.2), если они не указаны явно с помощью директивы ssl_session_ticket_key.

Можно использовать одновременно оба типа кэша, например:

однако использование только разделяемого кэша без встроенного должно быть более эффективным.

Синтаксис:	ssl_session_ticket_key файл ;
Умолчание:	—
Контекст:	http , server

Эта директива появилась в версии 1.5.7.

Задаёт файл с секретным ключом, применяемым при шифровании и расшифровании TLS session tickets. Директива необходима, если один и тот же ключ нужно использовать на нескольких серверах. По умолчанию используется случайно сгенерированный ключ.

Если указано несколько ключей, то только первый ключ используется для шифрования TLS session tickets. Это позволяет настроить ротацию ключей, например:

Файл должен содержать 80 или 48 байт случайных данных и может быть создан следующей командой:

В зависимости от размера файла для шифрования будет использоваться либо AES256 (для 80-байтных ключей, 1.11.8), либо AES128 (для 48-байтных ключей).

Умолчание:
Синтаксис:	ssl_session_tickets on \| off ;
Контекст:	http , server

Эта директива появилась в версии 1.5.9.

Разрешает или запрещает возобновление сессий при помощи TLS session tickets.

Умолчание:
Синтаксис:	ssl_session_timeout время ;
Контекст:	http , server

Задаёт время, в течение которого клиент может повторно использовать параметры сессии.

Умолчание:
Синтаксис:	ssl_stapling on \| off ;
Контекст:	http , server