My web server is (include version): nginx/1.18.0 (Ubuntu)
The operating system my web server runs on is (include version): Ubuntu 20.04 x64 LTS Linux raspberry 5.15.0-1032-raspi #35-Ubuntu SMP PREEMPT Wed Jun 7 16:00:54 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux
My hosting provider, if applicable, is: home network
My DNS provider, if applicable, is: OVH
I can log in to a root shell on my machine (yes or no, or I don't know): yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): I don't use certbot
I want to generate an SSL certificate with Ansible but the certificate is still in pending status (https://acme-v02.api.letsencrypt.org/acme/order/1170912057/190407197297). Is this normal to be that long ? it's been at least an hour since I generated the CSR and validated the certificate. How can certbot generate a valid certificate in seconds while I have to wait for it to be valid ?
I use Ansible to generate all the key,csr, ... I need :
I see your auth is pending but I don't see a TXT record. The best way to check is to use https://unboundtest.com for _acme-challenge.tholeb.fr and the rasp subdomain.
I'm not sure how long a DNS challenge could possibly stay pending. So, there may be something else happening that a more skilled volunteer will see. Or, maybe someone on the Ansible community as we don't see that client here often.
Still, the first thing I'd check is your method of creating the TXT record. If Let's Encrypt servers see an invalid TXT record they fail right away.
Thank you for your answer. It seems that my problem came from the TXT records, not created with the proper value. Now, for some reason, when I go to my website, Google Chrome asks me to take a certificate that comes from my IAP.
That's really weird because my nginx config have the proper certificate :
Well, it's hard to help with something I can't see.
Your service is clearly reacting differently depending on the requested domain. Does localhost and rasp.tholeb.fr resolve to the same IP? Does that service support SNI and does it use the correct cert for these different names.
You could try this which sets the host name for SNI
Adding my raspberry to the DMZ works, but it exposes the machine to the internet, which is not what I want because it's not safe at all, and I only want the websites to be accessible through local network only (the raspberry has a DNS server that redirects *.rasp.tholeb.fr > local network ip)
I don't understand here. rasp.tholeb.fr points to my raspberry (home), and localhost is when i'm connected to the rasp using SSH. I tried the commands above when I was connected to the rasp using SSH.
The output is :
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = *.rasp.tholeb.fr
verify return:1
---
Certificate chain
0 s:CN = *.rasp.tholeb.fr
i:C = US, O = Let's Encrypt, CN = R3
a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
v:NotBefore: Jun 23 11:59:49 2023 GMT; NotAfter: Sep 21 11:59:48 2023 GMT
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Sep 4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
i:O = Digital Signature Trust Co., CN = DST Root CA X3
a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
v:NotBefore: Jan 20 19:14:03 2021 GMT; NotAfter: Sep 30 18:14:03 2024 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIF/zCCBOegAwIBAgISA1ziVRK4q3J8Wt96AljFtrR1MA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMzA2MjMxMTU5NDlaFw0yMzA5MjExMTU5NDhaMBsxGTAXBgNVBAMM
ECoucmFzcC50aG9sZWIuZnIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC
AQD0vDFhj47C2zzde1G5294IUyyXXgWjcBo/0r7MDnYZmIHOdr2W+y4s5c8uIOsc
FD2e6U6BDG9ZY9ZWwnSVB/7bWLtrMekXmazC3p+Cj3Cle4B/KF5xi7W2PMLol/BB
F2AKH4p90q3au8g3WwsZUj2xUcHzxVhv/N91F7f8w4TIGZpsg474YWYvasUyGGa0
7hEfZvqJ0ddX+7h/Pq3+eAhOHxv492AHl6o9PzWZl848+2lIDY7L6ATi5wdlLhpa
CCnMQXiO3uNtefOZxGtFI2847MQ1f726tJdT21WRfM2aMDS4Dyf4eVtais5kN+qy
P0cRpfM7unFwF4Rqw1lriQiIMLT1myuO0Paog0LULABKEL96r0syyH13Lc0Mzr1n
Zk+/GZDKx3y2n3mAQKIlYZbaNnl8aBn93ki4iWRVlbCV5zsyPvk8EXyUdKG9nnqe
6qGggX84iMYhQ9e0bTX44+Qeh1sjUEt22hUAYHvmHYi0Un0u3PeCBMyyp+CZap3l
x54xnRnBuV0IaIbxWZeNbORIfdvG0DmRyZ4hz6caYPMBEUSSrDKAuYiXPLGEUfhB
BswaHB5lIzwAE3O0xXx8hGgjVhU1Bah59UswlRbmgriHjP2TCz5uWkVFEt9zQgPY
9UABPBO8y++DhYcJO9gryVOWe6sfT4tzPkx8yV0tf/UfzQIDAQABo4ICJDCCAiAw
DgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAM
BgNVHRMBAf8EAjAAMB0GA1UdDgQWBBRuTeisdx5vnM7//eQthO4KAIZPFzAfBgNV
HSMEGDAWgBQULrMXt1hWy65QCUDmH6+dixTCxjBVBggrBgEFBQcBAQRJMEcwIQYI
KwYBBQUHMAGGFWh0dHA6Ly9yMy5vLmxlbmNyLm9yZzAiBggrBgEFBQcwAoYWaHR0
cDovL3IzLmkubGVuY3Iub3JnLzArBgNVHREEJDAighAqLnJhc3AudGhvbGViLmZy
gg5yYXNwLnRob2xlYi5mcjATBgNVHSAEDDAKMAgGBmeBDAECATCCAQYGCisGAQQB
1nkCBAIEgfcEgfQA8gB3AHoyjFTYty22IOo44FIe6YQWcDIThU070ivBOlejUutS
AAABiOhW5xsAAAQDAEgwRgIhAI2lBM9cAm8h9xbvymz3AziHQa9rpiujP8G9LGuA
WXhrAiEAjRX1KiJT9k2nHsIcfv4TXweUHINAJbRuRTFoabu/jrYAdwDoPtDaPvUG
NTLnVyi8iWvJA9PL0RFr7Otp4Xd9bQa9bgAAAYjoVucyAAAEAwBIMEYCIQCUtJ+s
bscCVsqt55qAus6wMNBuZsyE80VGVk96gc39PQIhALkG2CtuAFLpuNh9DKFCrue6
TGM4q14JjMXlwYm/9BtPMA0GCSqGSIb3DQEBCwUAA4IBAQCQpkyMb1TSdZV2xGET
qLaRAjE5GzpViZwYpXWTsRGke7mUMw6hNpOkBTg6VSxkXFp/ouwirg0CyluRC5HF
39XpFuBtYykE8qmjnNtucH8cX+jWF619uhhDAACOeYGpuJfs8IL/p400D3/r78lo
PT8TwJZi3i/2X1XHL7Q5Hvz0pPbvfNZ7NjFtyUsXHa68tqSZ69qAMWZZlTivssaF
tgxKC+TIZvnwTAoHrvigl7YvHOEenI0Iblod8Nx0KiNoQcONV49aYlEjqBDU2btX
m10DJoHBvNPfPKmXNn1037lJ9kh4i1CnMRemwnp/RIKywHC30PGSRxZ67zotDV+0
W44b
-----END CERTIFICATE-----
subject=CN = *.rasp.tholeb.fr
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 5051 bytes and written 396 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 47E7221E06CF951016E686FF1CBC6AC2187B4E6AAAB197C0B63450BA3864E59D
Session-ID-ctx:
Resumption PSK: 568278BA9E9285B55EF2B834D2045BF76E1D1F8860FB2FC1A18DAF27044D9F323BA826406706C8C6095EA5F2ED9E2347
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 1d a6 15 dc 7d 70 87 6a-97 57 b6 bd 50 44 ad 9f ....}p.j.W..PD..
0010 - 06 d8 bd 7e d3 98 21 60-e5 8a b9 36 20 2b b5 b3 ...~..!`...6 +..
0020 - 19 35 50 df 91 24 94 7b-d4 70 03 15 93 ff b2 a2 .5P..$.{.p......
0030 - 80 79 b4 91 26 1c 04 26-c5 a7 65 d5 0a 0e 5b 47 .y..&..&..e...[G
0040 - a9 b3 16 70 cc 8f 92 bd-af f5 32 da b2 98 99 3a ...p......2....:
0050 - 2d 7b d6 9b bd 90 aa 83-ea f6 b4 44 cc 9a 62 94 -{.........D..b.
0060 - b0 e6 20 f6 74 93 86 38-f5 76 61 0d 80 af bd 31 .. .t..8.va....1
0070 - 45 7b 49 79 04 4c fc e7-f8 9e 7a d3 ed 98 63 de E{Iy.L....z...c.
0080 - 06 b6 c0 49 70 09 3e 27-fc f6 53 ab 2c 4e 0a c3 ...Ip.>'..S.,N..
0090 - 91 c9 ea 9e e7 af 12 cf-c4 7f 0d 90 09 14 50 76 ..............Pv
00a0 - b8 0a 2f fe 8a 76 66 0b-0e cb 15 3b 26 a8 ee 01 ../..vf....;&...
00b0 - 73 4a 89 88 7f d8 0e 77-bf ba e0 e8 1d 32 b1 19 sJ.....w.....2..
00c0 - 03 d3 19 79 e9 9e dc 4b-66 2e 2a 54 bd a2 71 22 ...y...Kf.*T..q"
00d0 - 9a 03 e9 11 fc d9 e0 e2-35 5d 07 77 da 78 0d 42 ........5].w.x.B
00e0 - df 64 99 96 03 3b 61 62-e5 17 1f 2a 5d b0 a3 27 .d...;ab...*]..'
Start Time: 1687528492
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 93A8FFF98EA41EDD94E8170050834CD2D07E97ED05E65005C6AD464484B805B7
Session-ID-ctx:
Resumption PSK: 3634AE186C83C5358CE2FB3054A9E1F45775255D3E2B28DC28FB7681548DB820878A8B8D85AEC682DC879CCD549C826D
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 1d a6 15 dc 7d 70 87 6a-97 57 b6 bd 50 44 ad 9f ....}p.j.W..PD..
0010 - d9 97 bf d3 9b 61 4d 33-b4 59 b1 9b 57 a3 f0 d3 .....aM3.Y..W...
0020 - b3 97 6b 8c 6d 62 93 b3-c8 93 df ab dd d9 28 83 ..k.mb........(.
0030 - 19 4f 64 21 9e e1 5d 1d-88 d5 59 45 17 71 f2 cf .Od!..]...YE.q..
0040 - d0 b9 39 24 69 0c a1 90-e6 fa 63 8d 40 0d 82 76 ..9$i.....c.@..v
0050 - 1d 8a 9c 56 0a e3 4a 4a-bb e9 24 c5 51 8f 4b 98 ...V..JJ..$.Q.K.
0060 - 43 c7 f9 1a 5d eb 44 2f-4c 59 0a 3e 65 30 6f 42 C...].D/LY.>e0oB
0070 - e9 46 5a f8 b3 c8 ec d2-fa 5b 7d dc a4 ef 9f e9 .FZ......[}.....
0080 - 2b ad 53 d5 77 a6 0c 03-17 42 cf 68 cf 41 5d a4 +.S.w....B.h.A].
0090 - b7 02 65 09 1f 80 8b 3c-81 65 67 88 88 ad 7c a3 ..e....<.eg...|.
00a0 - b6 94 c4 0b 99 44 3c 92-6b 81 ef 81 89 76 27 cf .....D<.k....v'.
00b0 - c7 cc ad 6c 8e cb a8 8a-45 18 b4 e2 b7 87 56 1e ...l....E.....V.
00c0 - 6d bc 9b 8b 06 f9 d4 96-41 97 6f 8e e2 92 6e 9a m.......A.o...n.
00d0 - 8a d3 54 c0 dd fc a8 54-10 36 2c 04 32 d5 49 dd ..T....T.6,.2.I.
00e0 - 6c e6 e6 6a 40 74 b7 6f-38 38 99 d5 15 bd 96 d2 l..j@t.o88......
Start Time: 1687528492
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
After some more digging, the certificate gave by Orange (my IAP) is indeed a bug, but, I resolved my problem by checking my local DNS (on my raspberry), and it wasn't started for some reason. Thanks a lot for the help !