Перенаправление HTTP на https приводит к сбою в получении новых сертификатов
Я пытался перенаправить HTTP-запрос на порт 80 в nginx.conf
server {
listen 80;
server_name _;
location /.well-known/acme-challenge/ {
content_by_lua_block {
auto_ssl:challenge_server()
}
}
return 301 https://$host$request_uri;
}
Это показывает ошибку, подобную этой
Processing five.fortunekit.com
+ Creating new directory /etc/resty-auto-ssl/letsencrypt/certs/five.fortunekit.com ...
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting new certificate order from CA...
+ Received 1 authorizations URLs from the CA
+ Handling authorization for five.fortunekit.com
+ 1 pending challenge(s)
+ Deploying challenge tokens...
deploy_challenge
+ Responding to challenge for five.fortunekit.com authorization...
invalid_challenge
Invalid challenge: DOMAIN=five.fortunekit.com RESPONSE={
"type": "http-01",
"status": "invalid",
"error": {
"type": "urn:ietf:params:acme:error:connection",
"detail": "Fetching https://five.fortunekit.com/.well-known/acme-challenge/geyhMh-KOQTyNQRDIurMja32h3Xjd4nmiE9UkFBn15w: Timeout after connect (your server may be slow or overloaded)",
"status": 400
},
"url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/4699231438/-vRiFQ",
"token": "geyhMh-KOQTyNQRDIurMja32h3Xjd4nmiE9UkFBn15w",
"validationRecord": [
{
"url": "http://five.fortunekit.com/.well-known/acme-challenge/geyhMh-KOQTyNQRDIurMja32h3Xjd4nmiE9UkFBn15w",
"hostname": "five.fortunekit.com",
"port": "80",
"addressesResolved": [
"35.154.129.216"
],
"addressUsed": "35.154.129.216"
},
{
"url": "https://five.fortunekit.com/.well-known/acme-challenge/geyhMh-KOQTyNQRDIurMja32h3Xjd4nmiE9UkFBn15w",
"hostname": "five.fortunekit.com",
"port": "443",
"addressesResolved": [
"35.154.129.216"
],
"addressUsed": "35.154.129.216"
}
]
}
err: Can't load ./.rnd into RNG
140653820678592:error:2406F079:random number generator:RAND_load_file:Cannot open file:../crypto/rand/randfile.c:88:Filename=./.rnd
, context: ssl_certificate_by_lua*, client: 106.210.248.44, server: 0.0.0.0:443
2020/05/20 10:36:17 [error] 4144#4144: *4 [lua] ssl_certificate.lua:97: issue_cert(): auto-ssl: issuing new certificate failed: dehydrated failure, context: ssl_certificate_by_lua*, client: 106.210.248.44, server: 0.0.0.0:443
2020/05/20 10:36:17 [error] 4144#4144: *4 [lua] ssl_certificate.lua:291: auto-ssl: could not get certificate for five.fortunekit.com - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: 106.210.248.44, server: 0.0.0.0:443
2020/05/20 10:36:35 [error] 4144#4144: *12 [lua] ssl_certificate.lua:68: issue_cert(): auto-ssl: failed to obtain lock: timeout, context: ssl_certificate_by_lua*, client: 66.133.109.36, server: 0.0.0.0:443
2020/05/20 10:36:35 [error] 4144#4144: *12 [lua] ssl_certificate.lua:291: auto-ssl: could not get certificate for five.fortunekit.com - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: 66.133.109.36, server: 0.0.0.0:443
2020/05/20 10:36:36 [error] 4144#4144: *16 [lua] ssl_certificate.lua:68: issue_cert(): auto-ssl: failed to obtain lock: timeout, context: ssl_certificate_by_lua*, client: 34.209.232.166, server: 0.0.0.0:443
Это приводит к ошибке 429, например
{
"type": "urn:ietf:params:acme:error:rateLimited",
"detail": "Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/",
"status": 429
}
У меня такая же проблема. Однако решение неочевидно, если вы не разбираетесь в том, как nginx выбирает блоки location
.
Решение :
# wildcard HTTP server for domains
server {
listen 80;
server_name _;
# Endpoint used for performing domain verification with Let's Encrypt.
location /.well-known/acme-challenge/ {
content_by_lua_block {
auto_ssl:challenge_server()
}
}
location / {
return 301 https://$host$request_uri;
}
Почему это работает, а ваш пример - нет: потому что у вас есть оператор return в корне сервера, поэтому nginx видит это и напрямую возвращает 301 вместо того, чтобы сначала соответствовать вашему местоположению. Итак, не используйте return
в корне сервера. Когда-либо.
Сейчас он работает. Большое спасибо :)
Самый полезный комментарий
У меня такая же проблема. Однако решение неочевидно, если вы не разбираетесь в том, как nginx выбирает блоки
location
.Решение :
Почему это работает, а ваш пример - нет: потому что у вас есть оператор return в корне сервера, поэтому nginx видит это и напрямую возвращает 301 вместо того, чтобы сначала соответствовать вашему местоположению. Итак, не используйте
return
в корне сервера. Когда-либо.