Perguntas[ssl](server)

Tenho um servidor Apache HTTPS voltado para a Internet current.example.com. Quero renomear o servidor web para nextname.example.com. Também preciso que current.example.com continue funcionando durante a transição. Esta é apenas uma mudança de nome, e o mesmo conteúdo do mesmo local será servido.

Comecei adicionando um ServerAlias ​​às minhas configurações de virtualhost (HTTP e HTTPS). Isso resultou na mensagem "sua conexão não é privada" ao acessar nextname.example.com. Eu esperava que isso ocorresse.

Eu sei que uma (talvez a única?) solução é criar um novo certificado para nextname e criar uma nova configuração VirtualHost.

Mas espero outra solução.

Além disso, percebo que uma nova chave privada não é obrigatória, mas provavelmente é aconselhável, pois já precisaremos de um novo certificado.

Existe uma maneira de configurar para que o certificado possa ser usado/compartilhado por ambos os servidores virtuais ou é necessário um novo certificado para manter o nome antigo?

Tenho um host virtual que redireciona não-www para www via SSL:

<VirtualHost *:443>
  ServerName example.com
  Redirect / https://www.example.com/
  # Do I need to include SSL configuration here?
</VirtualHost >

# Main Site
<VirtualHost *:443>
  ServerName www.example.com
  Redirect / https://www.example.com/
  # Rest of the configurations including SSL
</VirtualHost >

Preciso incluir a configuração SSL e os certificados no primeiro bloco vhost que só faz redirecionamento? Se eu omitir a configuração SSL no primeiro bloco vhost, o redirecionamento e o site ainda funcionam bem, então por que preciso colocar os certificados SSL no primeiro bloco vhost?

Tenho um servidor web Scala+AKKA que usa https, juntamente com um aplicativo web React+NextUI que usa ssl. O sistema operacional do servidor real executa nginx e redireciona as chamadas apropriadamente para o next ou para o servidor web Scala.

Gostaria de entender se devo gerar certificados SSL apenas para o nginx e usá-los para os outros aplicativos por trás dele ou se todos eles precisam de certificados separados?

Se alguém pudesse explicar o processo, seria incrível. SSL é muito novo para mim.

EDITAR:

Estou usando o cryptmódulo javascript, portanto DEVO iniciar o Next com https. Não tenho escolha nisso, pois o crypt não funcionará sem conexão ssl. Então, apenas configurar ssl com nginxe deixá-lo passar para next como http não é uma opção

Estou configurando o haproxy para atuar como intermediário entre a internet e vários serviços executados em um cluster k8s isolado.

Já testei com sucesso a conexão com o backend via http simples, mas agora estou tentando manipular o componente SSL lá também e, por algum motivo, não importa o que eu tente, estou recebendo o seguinte nos logs:

Jan 22 11:10:22 jake haproxy[170526]: 95.214.55.185:34832 [22/Jan/2025:11:10:21.968] xanadu-ingress-front/3: SSL handshake failure (error:0A000076:SSL routines::no suitable signature algorithm)

Tentar solucionar problemas via openssl s_clientme dá o seguinte (endereços IP e nomes DNS alterados para proteger o culpado):

shadur@luminosity:~$ openssl s_client --connect teapot.example.com:443 
Connecting to 1.2.3.4 CONNECTED(00000003)
40E7B2BBBA7F0000:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:../ssl/record/rec_layer_s3.c:907:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 335 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

arquivo de configuração do haproxy abaixo:

global
        log /dev/log    local0
        log /dev/log    local1 notice
        chroot /var/lib/haproxy
        stats socket /run/haproxy/admin.sock mode 660 level admin
        stats timeout 30s
        user haproxy
        group haproxy
        daemon

        # Default SSL material locations
        ca-base /etc/ssl/certs
        crt-base /etc/ssl/private


        # generated 2025-01-22, Mozilla Guideline v5.7, HAProxy 3.1.2, OpenSSL 3.4.0, intermediate config
        # https://ssl-config.mozilla.org/#server=haproxy&version=3.1.2&config=intermediate&openssl=3.4.0&guideline=5.7
        # intermediate configuration
        ssl-default-bind-curves X25519:prime256v1:secp384r1
        ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
        ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
        ssl-default-bind-options prefer-client-ciphers ssl-min-ver TLSv1.2 no-tls-tickets

        ssl-default-server-curves X25519:prime256v1:secp384r1
        ssl-default-server-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
        ssl-default-server-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
        ssl-default-server-options ssl-min-ver TLSv1.2 no-tls-tickets

        # curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam
        ssl-dh-param-file /etc/ssl/private/dhparam


defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        timeout connect 5000
        timeout client  50000
        timeout server  50000
        errorfile 400 /etc/haproxy/errors/400.http
        errorfile 403 /etc/haproxy/errors/403.http
        errorfile 408 /etc/haproxy/errors/408.http
        errorfile 500 /etc/haproxy/errors/500.http
        errorfile 502 /etc/haproxy/errors/502.http
        errorfile 503 /etc/haproxy/errors/503.http
        errorfile 504 /etc/haproxy/errors/504.http

crt-store company
  crt-base /etc/ssl/certs/
  key-base /etc/ssl/private/
  load crt "company.com-full.pem" key "company.nl.key" alias "company"
  load crt "company.net-full.pem" key "company.net.key" alias "company.net"

frontend xanadu-ingress-front
  bind 1.2.3.4:80
  bind 1:2:3:4:5:6:7:8:80 transparent
  bind 1.2.3.4:443 ssl crt-list /etc/ssl/crt-lists/company.list alpn h2,http/1.1
  http-request redirect scheme https unless { ssl_fc }
  default_backend xanadu-ingress-back
  option httplog

backend xanadu-ingress-back
  mode http
  server xanadu 172.16.41.80:80 check

Tenho quase certeza de que estou esquecendo de algo muito simples e óbvio, mas não consigo descobrir o que é. Qualquer ajuda seria apreciada.

Alguns sites falham nas solicitações HTTP do meu VPS.

Por exemplo, https://openvpn.net falha em uma solicitação:

root@vm3226933:~# curl -vvvv --head https://openvpn.net
*   Trying 104.19.190.106:443...
* Connected to openvpn.net (104.19.190.106) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to openvpn.net:443
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to openvpn.net:443

Solicitação adicional de baixo nível:

root@vm3226933:~# openssl s_client -connect openvpn.net:443 -debug -trace
CONNECTED(00000003)
Sent Record
Header:
  Version = TLS 1.0 (0x301)
  Content Type = Handshake (22)
  Length = 312
    ClientHello, Length=308
      client_version=0x303 (TLS 1.2)
      Random:
        gmt_unix_time=0x5284377E
        random_bytes (len=28): 8E8BCFC1833EC97B58643C21A64FA2CBC6A3DE29BC3D5361FDFC29EC
      session_id (len=32): CCFFFE0BE78882B46FA491614BE65EBCE2852139F82D614E75B3DFC85C2E7F6F
      cipher_suites (len=62)
        {0x13, 0x02} TLS_AES_256_GCM_SHA384
        {0x13, 0x03} TLS_CHACHA20_POLY1305_SHA256
        {0x13, 0x01} TLS_AES_128_GCM_SHA256
        {0xC0, 0x2C} TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
        {0xC0, 0x30} TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
        {0x00, 0x9F} TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
        {0xCC, 0xA9} TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
        {0xCC, 0xA8} TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
        {0xCC, 0xAA} TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
        {0xC0, 0x2B} TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
        {0xC0, 0x2F} TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        {0x00, 0x9E} TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
        {0xC0, 0x24} TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
        {0xC0, 0x28} TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
        {0x00, 0x6B} TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
        {0xC0, 0x23} TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
        {0xC0, 0x27} TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
        {0x00, 0x67} TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
        {0xC0, 0x0A} TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
        {0xC0, 0x14} TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
        {0x00, 0x39} TLS_DHE_RSA_WITH_AES_256_CBC_SHA
        {0xC0, 0x09} TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
        {0xC0, 0x13} TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
        {0x00, 0x33} TLS_DHE_RSA_WITH_AES_128_CBC_SHA
        {0x00, 0x9D} TLS_RSA_WITH_AES_256_GCM_SHA384
        {0x00, 0x9C} TLS_RSA_WITH_AES_128_GCM_SHA256
        {0x00, 0x3D} TLS_RSA_WITH_AES_256_CBC_SHA256
        {0x00, 0x3C} TLS_RSA_WITH_AES_128_CBC_SHA256
        {0x00, 0x35} TLS_RSA_WITH_AES_256_CBC_SHA
        {0x00, 0x2F} TLS_RSA_WITH_AES_128_CBC_SHA
        {0x00, 0xFF} TLS_EMPTY_RENEGOTIATION_INFO_SCSV
      compression_methods (len=1)
        No Compression (0x00)
      extensions, length = 173
        extension_type=server_name(0), length=16
          0000 - 00 0e 00 00 0b 6f 70 65-6e 76 70 6e 2e 6e 65   .....openvpn.ne
          000f - 74                                             t
        extension_type=ec_point_formats(11), length=4
          uncompressed (0)
          ansiX962_compressed_prime (1)
          ansiX962_compressed_char2 (2)
        extension_type=supported_groups(10), length=22
          ecdh_x25519 (29)
          secp256r1 (P-256) (23)
          ecdh_x448 (30)
          secp521r1 (P-521) (25)
          secp384r1 (P-384) (24)
          ffdhe2048 (256)
          ffdhe3072 (257)
          ffdhe4096 (258)
          ffdhe6144 (259)
          ffdhe8192 (260)
        extension_type=session_ticket(35), length=0
        extension_type=encrypt_then_mac(22), length=0
        extension_type=extended_master_secret(23), length=0
        extension_type=signature_algorithms(13), length=42
          ecdsa_secp256r1_sha256 (0x0403)
          ecdsa_secp384r1_sha384 (0x0503)
          ecdsa_secp521r1_sha512 (0x0603)
          ed25519 (0x0807)
          ed448 (0x0808)
          rsa_pss_pss_sha256 (0x0809)
          rsa_pss_pss_sha384 (0x080a)
          rsa_pss_pss_sha512 (0x080b)
          rsa_pss_rsae_sha256 (0x0804)
          rsa_pss_rsae_sha384 (0x0805)
          rsa_pss_rsae_sha512 (0x0806)
          rsa_pkcs1_sha256 (0x0401)
          rsa_pkcs1_sha384 (0x0501)
          rsa_pkcs1_sha512 (0x0601)
          ecdsa_sha224 (0x0303)
          rsa_pkcs1_sha224 (0x0301)
          dsa_sha224 (0x0302)
          dsa_sha256 (0x0402)
          dsa_sha384 (0x0502)
          dsa_sha512 (0x0602)
        extension_type=supported_versions(43), length=9
          TLS 1.3 (772)
          TLS 1.2 (771)
          TLS 1.1 (770)
          TLS 1.0 (769)
        extension_type=psk_key_exchange_modes(45), length=2
          psk_dhe_ke (1)
        extension_type=key_share(51), length=38
            NamedGroup: ecdh_x25519 (29)
            key_exchange:  (len=32): 1B7EC7B0AE2011F2A401C8E0A4B9E866D566027013D37EE4ADFE0F39393C8156

write to 0x555d7a5089c0 [0x555d7a51f070] (317 bytes => 317 (0x13D))
0000 - 16 03 01 01 38 01 00 01-34 03 03 52 84 37 7e 8e   ....8...4..R.7~.
0010 - 8b cf c1 83 3e c9 7b 58-64 3c 21 a6 4f a2 cb c6   ....>.{Xd<!.O...
0020 - a3 de 29 bc 3d 53 61 fd-fc 29 ec 20 cc ff fe 0b   ..).=Sa..). ....
0030 - e7 88 82 b4 6f a4 91 61-4b e6 5e bc e2 85 21 39   ....o..aK.^...!9
0040 - f8 2d 61 4e 75 b3 df c8-5c 2e 7f 6f 00 3e 13 02   .-aNu...\..o.>..
0050 - 13 03 13 01 c0 2c c0 30-00 9f cc a9 cc a8 cc aa   .....,.0........
0060 - c0 2b c0 2f 00 9e c0 24-c0 28 00 6b c0 23 c0 27   .+./...$.(.k.#.'
0070 - 00 67 c0 0a c0 14 00 39-c0 09 c0 13 00 33 00 9d   .g.....9.....3..
0080 - 00 9c 00 3d 00 3c 00 35-00 2f 00 ff 01 00 00 ad   ...=.<.5./......
0090 - 00 00 00 10 00 0e 00 00-0b 6f 70 65 6e 76 70 6e   .........openvpn
00a0 - 2e 6e 65 74 00 0b 00 04-03 00 01 02 00 0a 00 16   .net............
00b0 - 00 14 00 1d 00 17 00 1e-00 19 00 18 01 00 01 01   ................
00c0 - 01 02 01 03 01 04 00 23-00 00 00 16 00 00 00 17   .......#........
00d0 - 00 00 00 0d 00 2a 00 28-04 03 05 03 06 03 08 07   .....*.(........
00e0 - 08 08 08 09 08 0a 08 0b-08 04 08 05 08 06 04 01   ................
00f0 - 05 01 06 01 03 03 03 01-03 02 04 02 05 02 06 02   ................
0100 - 00 2b 00 09 08 03 04 03-03 03 02 03 01 00 2d 00   .+............-.
0110 - 02 01 01 00 33 00 26 00-24 00 1d 00 20 1b 7e c7   ....3.&.$... .~.
0120 - b0 ae 20 11 f2 a4 01 c8-e0 a4 b9 e8 66 d5 66 02   .. .........f.f.
0130 - 70 13 d3 7e e4 ad fe 0f-39 39 3c 81 56            p..~....99<.V
read from 0x555d7a5089c0 [0x555d7a516e53] (5 bytes => -1)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 317 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
read from 0x555d7a5089c0 [0x555d7a3f1080] (8192 bytes => 0)

In the same time other sites return HTTP 200:
root@vm3226933:~# curl -vvvv --head https://pq.hosting
*   Trying 5.252.34.78:443...
* Connected to pq.hosting (5.252.34.78) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=*.pq.hosting
*  start date: Jun 17 13:20:00 2024 GMT
*  expire date: Jul 19 13:19:59 2025 GMT
*  subjectAltName: host "pq.hosting" matched cert's "pq.hosting"
*  issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign GCC R6 AlphaSSL CA 2023
*  SSL certificate verify ok.
* using HTTP/2
* h2h3 [:method: HEAD]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: pq.hosting]
* h2h3 [user-agent: curl/7.88.1]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x55fa9d20dce0)
> HEAD / HTTP/2
> Host: pq.hosting
> user-agent: curl/7.88.1
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 200
HTTP/2 200
< server: nginx
server: nginx
< date: Mon, 30 Dec 2024 19:30:55 GMT
date: Mon, 30 Dec 2024 19:30:55 GMT
< content-length: 13534
content-length: 13534
< set-cookie: __js_p_=55,1800,0,0,1; Path=/
set-cookie: __js_p_=55,1800,0,0,1; Path=/
< cache-control: no-cache
cache-control: no-cache
< content-type: text/html; charset=utf-8
content-type: text/html; charset=utf-8

<
* Connection #0 to host pq.hosting left intact

O VPS é apt-updated e apt-upgraded, tem o openssl mais recente:

root@vm3226933:~# uname -a
Linux vm3226933.stark-industries.solutions 6.1.0-26-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.112-1 (2024-09-30) x86_64 GNU/Linux
root@vm3226933:~# cat /etc/debian_version
12.8
root@vm3226933:~# openssl version
OpenSSL 3.0.15 3 Sep 2024 (Library: OpenSSL 3.0.15 3 Sep 2024)

Para diagnosticar o problema, instalei o Linux localmente e solicitei o site 'defeituoso':

debian12@debian12:~$ curl -vvvv --head https://openvpn.net
*   Trying 104.19.190.106:443...
* Connected to openvpn.net (104.19.190.106) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=*.openvpn.net
*  start date: Feb  5 21:17:59 2024 GMT
*  expire date: Feb  5 16:13:59 2025 GMT
*  subjectAltName: host "openvpn.net" matched cert's "openvpn.net"
*  issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2
*  SSL certificate verify ok.
* using HTTP/2
* h2h3 [:method: HEAD]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: openvpn.net]
* h2h3 [user-agent: curl/7.88.1]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x5596424bace0)
> HEAD / HTTP/2
> Host: openvpn.net
> user-agent: curl/7.88.1
> accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 200 
HTTP/2 200 
< date: Mon, 30 Dec 2024 19:19:09 GMT
date: Mon, 30 Dec 2024 19:19:09 GMT
< content-type: text/html
content-type: text/html
< last-modified: Thu, 28 Nov 2024 17:28:54 GMT
last-modified: Thu, 28 Nov 2024 17:28:54 GMT
< etag: W/"6748a856-399b4"
etag: W/"6748a856-399b4"
< cf-cache-status: HIT
cf-cache-status: HIT
< age: 5590
age: 5590
< expires: Tue, 31 Dec 2024 00:19:09 GMT
expires: Tue, 31 Dec 2024 00:19:09 GMT
< cache-control: public, max-age=18000
cache-control: public, max-age=18000
< server: cloudflare
server: cloudflare
< cf-ray: 8fa4613e7b66f117-DME
cf-ray: 8fa4613e7b66f117-DME

< 
* Connection #0 to host openvpn.net left intact

Possui o mesmo software:

debian12@debian12:~$ uname -a
Linux debian12 6.1.0-27-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.115-1 (2024-11-01) x86_64 GNU/Linux
debian12@debian12:~$ cat /etc/debian_version 
12.8
debian12@debian12:~$ openssl version
OpenSSL 3.0.15 3 Sep 2024 (Library: OpenSSL 3.0.15 3 Sep 2024)

Meu provedor de hospedagem informa que os servidores bloqueiam solicitações.

Está certo ou o openssl está configurado incorretamente?

Meu domínio androz2091.fr está apontando para um cluster kubernetes de nó único. O Caddy está instalado no nó (no host, não dentro do k8s) e usa o DNS do cluster para redirecionar para o serviço certo.

Aqui está meu Caddyfile . Aqui está minha documentação de cluster .

Infelizmente, a cada 30 a 50 solicitações ao acessar meu domínio, recebo este erro:

poca@localhost:~ $ wget androz2091.fr
--2024-11-15 10:45:55--  http://androz2091.fr/
Resolving androz2091.fr (androz2091.fr)... HIDDEN-IP
Connecting to androz2091.fr (androz2091.fr)|HIDDEN-IP|:80... connected.
HTTP request sent, awaiting response... 308 Permanent Redirect
Location: https://androz2091.fr/ [following]
--2024-11-15 10:45:55--  https://androz2091.fr/
Connecting to androz2091.fr (androz2091.fr)|HIDDEN-IP|:443... connected.
OpenSSL: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
Unable to establish SSL connection.

Por onde começo a procurar o problema?

Não tenho ideia de como depurá-lo (nem está aparecendo em cada solicitação) e qual parte do meu cluster pode estar com defeito. Posso fornecer mais informações, se necessário.

Habilitei o SSL no meu banco de dados PostgreSQL e o apliquei usando pg_hba.confa seguinte linha:

hostssl all all 0.0.0.0/0 md5

A partir dos logs de conexão do PostgreSQL e do tráfego de rede capturado via tcpdump, parece que conexões SSL estão sendo feitas:

2024-10-20 10:12:16.140 UTC [63] LOG:  connection authenticated: identity="user" method=md5 (/etc/postgresql/pg_hba.conf:136)
2024-10-20 10:12:16.140 UTC [63] LOG:  connection authorized: user=user database=db SSL enabled (protocol=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256)

No entanto, como o Dovecot e o PostgreSQL estão sendo executados em máquinas diferentes e o certificado e sua CA não são confiáveis ​​na máquina dovecot, eu esperava que o Dovecot, que se conecta ao PostgreSQL, sinalizasse um problema com o certificado autoassinado, mas não há reclamações. Isso me leva a acreditar que o certificado não está sendo validado corretamente, tornando a conexão vulnerável a ataques como MITM (Man-in-the-Middle).

Há alguma configuração extra ou etapa que estou esquecendo para impor a validação do certificado? Como posso garantir que as conexões sejam seguras e que o certificado esteja sendo validado corretamente?

Eu administro um site científico, chamo de site.org, que é espelhado em três locais, todos listados no DNS como site.org para que os clientes escolham um espelho específico aleatoriamente. Os espelhos individuais são server1.site.org, etc. O certificado LetsEncrypt cobre site.org mais os nomes dos espelhos. Todos os espelhos estão dentro de universidades que estão doando largura de banda; não tenho financiamento para pagar pela largura de banda sozinho.

Uma universidade, univ.edu, decidiu recentemente que para "controle de segurança da comunicação https" (palavras deles) todos os sites dentro de sua rede devem estar atrás de seu certificado curinga *.univ.edu. A implementação deles é que no firewall, quando eles veem uma conexão de porta 443, eles interceptam o handshake SSL e substituem seu próprio certificado. Meu servidor nunca vê o handshake do certificado. O navegador do cliente vê o certificado *.univ.edu e o rejeita porque ele não cobre site.org. Pedi que o IP do meu servidor fosse colocado na lista de permissões para passagem, e eles disseram que fazer isso "não era possível".

Para mim, substituir o certificado deles pelo meu parece um ataque de adversário no meio. Para ser justo, não sei se eles estão realmente sentados lá e monitorando o tráfego, mas não vejo nada que os impeça de fazer isso. Não dou a mínima para o monitoramento para meus próprios propósitos (tudo no site é público de qualquer maneira), mas parece uma má ideia para mim, embora torne muito mais fácil para eles gerenciarem certificados para sites dentro do univ.edu.

Então: é normal que grandes organizações usem uma abordagem AITM para gerenciar certificados? Isso é realmente só porque eles querem bisbilhotar todas as conexões (de entrada, mas não de saída)? Há razões que eu não pensei para que isso seja uma Má Ideia?

Fundamentalmente, estou procurando argumentos fortes que eu possa usar para convencê-los a sair de sua posição. Se eles não cederem, temo que terei que desligar o espelho, o que seria triste para meus usuários, porque esse espelho tem uma largura de banda muito melhor para o continente em que está localizado. (Sugestões alternativas seriam apreciadas, no entanto!)

Eu tenho um servidor cPanel no qual escrevi um arquivo de configuração incluído com um proxy reverso para apontá-lo para um aplicativo de reação hospedado no servidor.

Aqui está um exemplo:

 ServerName my.website

ProxyRequests off

<Proxy *>
        Order deny,allow
        Allow from all
</Proxy>

<Location />
        ProxyPass http://localhost:8080/
        ProxyPassReverse http://localhost:8080/
</Location>

Meu servidor usa o Let's Encrypt AutoSSL para proteger o domínio, mas o arquivo de configuração causa problemas de redirecionamento, impedindo que o AutoSSL proteja o domínio. Tentei várias isenções para ignorar o arquivo DCV, mas nenhuma teve sucesso até agora. Como posso escrevê-lo para que o AutoSSL continue a proteger meu domínio, mesmo com o proxy reverso instalado.

Sou o autor do checkdmarc, uma ferramenta CLI de código aberto para verificar DMARC e outros padrões de segurança de e-mail. Uma dessas verificações envolve testar se os servidores de e-mail listados nos MXregistros de um domínio oferecem suporte a TLS. Estou descobrindo que, em muitas situações, os nomes de host listados no registro MX de um domínio não correspondem aos CNvalores de nomes alternativos do certificado usado por esse servidor. Isso faz com que as conexões TLS com esses hosts falhem devido à incompatibilidade do nome do host.

Por exemplo, os registros MX para gmail.comsão:

gmail.com.              1550    IN      MX      20 alt2.gmail-smtp-in.l.google.com.
gmail.com.              1550    IN      MX      40 alt4.gmail-smtp-in.l.google.com.
gmail.com.              1550    IN      MX      10 alt1.gmail-smtp-in.l.google.com.
gmail.com.              1550    IN      MX      5 gmail-smtp-in.l.google.com.
gmail.com.              1550    IN      MX      30 alt3.gmail-smtp-in.l.google.com.

No entanto, uma rápida inspeção do certificado gmail-smtp-in.l.google.commostra que o CN do certificado oferecido por esse host é mx.google.com. Como posso explicar isso? Os clientes de e-mail estão simplesmente ignorando a correspondência de nomes de host nos servidores MX? Isso parece loucura!

openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp
CONNECTED(00000003)
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
verify return:1
depth=1 C = US, O = Google Trust Services, CN = WR2
verify return:1
depth=0 CN = mx.google.com
verify return:1
---
Certificate chain
 0 s:CN = mx.google.com
   i:C = US, O = Google Trust Services, CN = WR2
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jun 24 07:37:53 2024 GMT; NotAfter: Sep 16 07:37:52 2024 GMT
 1 s:C = US, O = Google Trust Services, CN = WR2
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Dec 13 09:00:00 2023 GMT; NotAfter: Feb 20 14:00:00 2029 GMT
 2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jun 19 00:00:42 2020 GMT; NotAfter: Jan 28 00:00:42 2028 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGwjCCBaqgAwIBAgIQZZLFVIncLgcKOAT21sXTxzANBgkqhkiG9w0BAQsFADA7
MQswCQYDVQQGEwJVUzEeMBwGA1UEChMVR29vZ2xlIFRydXN0IFNlcnZpY2VzMQww
CgYDVQQDEwNXUjIwHhcNMjQwNjI0MDczNzUzWhcNMjQwOTE2MDczNzUyWjAYMRYw
FAYDVQQDEw1teC5nb29nbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE
EPY8iG+t2yuh+G2C7yURtlapDVtP5VYg0EifYWjDqqP0wUDTG82xOglMV1f5KGEy
B2L1MQVnrBxS7jgN72+tS6OCBK4wggSqMA4GA1UdDwEB/wQEAwIHgDATBgNVHSUE
DDAKBggrBgEFBQcDATAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBRiyEisYHpKSLmB
lAKrUL9Fess8uDAfBgNVHSMEGDAWgBTeGx7teRXUPjckwyG77DQ5bUKyMDBYBggr
BgEFBQcBAQRMMEowIQYIKwYBBQUHMAGGFWh0dHA6Ly9vLnBraS5nb29nL3dyMjAl
BggrBgEFBQcwAoYZaHR0cDovL2kucGtpLmdvb2cvd3IyLmNydDCCAoYGA1UdEQSC
An0wggJ5gg1teC5nb29nbGUuY29tgg9zbXRwLmdvb2dsZS5jb22CEmFzcG14Lmwu
Z29vZ2xlLmNvbYIXYWx0MS5hc3BteC5sLmdvb2dsZS5jb22CF2FsdDIuYXNwbXgu
bC5nb29nbGUuY29tghdhbHQzLmFzcG14LmwuZ29vZ2xlLmNvbYIXYWx0NC5hc3Bt
eC5sLmdvb2dsZS5jb22CGmdtYWlsLXNtdHAtaW4ubC5nb29nbGUuY29tgh9hbHQx
LmdtYWlsLXNtdHAtaW4ubC5nb29nbGUuY29tgh9hbHQyLmdtYWlsLXNtdHAtaW4u
bC5nb29nbGUuY29tgh9hbHQzLmdtYWlsLXNtdHAtaW4ubC5nb29nbGUuY29tgh9h
bHQ0LmdtYWlsLXNtdHAtaW4ubC5nb29nbGUuY29tghhnbXItc210cC1pbi5sLmdv
b2dsZS5jb22CHWFsdDEuZ21yLXNtdHAtaW4ubC5nb29nbGUuY29tgh1hbHQyLmdt
ci1zbXRwLWluLmwuZ29vZ2xlLmNvbYIdYWx0My5nbXItc210cC1pbi5sLmdvb2ds
ZS5jb22CHWFsdDQuZ21yLXNtdHAtaW4ubC5nb29nbGUuY29tgg1teDEuc210cC5n
b29ngg1teDIuc210cC5nb29ngg1teDMuc210cC5nb29ngg1teDQuc210cC5nb29n
ghVhc3BteDIuZ29vZ2xlbWFpbC5jb22CFWFzcG14My5nb29nbGVtYWlsLmNvbYIV
YXNwbXg0Lmdvb2dsZW1haWwuY29tghVhc3BteDUuZ29vZ2xlbWFpbC5jb22CEWdt
ci1teC5nb29nbGUuY29tMBMGA1UdIAQMMAowCAYGZ4EMAQIBMDYGA1UdHwQvMC0w
K6ApoCeGJWh0dHA6Ly9jLnBraS5nb29nL3dyMi85VVZiTjB3NUU2WS5jcmwwggEC
BgorBgEEAdZ5AgQCBIHzBIHwAO4AdQDuzdBk1dsazsVct520zROiModGfLzs3sNR
SFlGcR+1mwAAAZBJZQCtAAAEAwBGMEQCIEpVY7zgwrSNfBuWwgIeM0tTPxSQ6Swm
9x8o0wspJLNUAiA+16PpwOPDzPyvS1hBoRfFLD+11s2cKbxY3OXAma3wWQB1ANq2
v2s/tbYin5vCu1xr6HCRcWy7UYSFNL2kPTBI1/urAAABkEllANgAAAQDAEYwRAIg
bUppm6ugUYNlSakwgDF9/iV4yLTfd1gL53XsQOtEfewCIFNMdgwPXxIozNmwgEvT
TDbyFlh6OHe6mTmivcTzICK3MA0GCSqGSIb3DQEBCwUAA4IBAQBMvON+VaXWy4yH
ruDpCBvW2EO9sdVvefqPJHgda2yGqyRq1BQmnhLaIQhaJpEsdhrl/spLykOkZo8o
3R4W1dq24zXwNq0Qv1ThuH+WA8wr8tiZwd4yIDSqahsAtJm2K31logFAuDX771LB
MmtOZbkiDk9Ist2pmGRTP0Z7VpJy12aG/hUoeqcN1FmrWCNKG7ycMIVrairGrI4A
8wa5dUpDwezKaP3V3U8o9btRcuRD8doKFTPhzas+d1EZ1mtS/m9nKR1ssGfjtKFX
7zyNb+OoZOES1JpEjke3vc1iwkri+PkG+KuREsvFvb0sK6X6Gq0xE8EF25765UGz
vuIwywDO
-----END CERTIFICATE-----
subject=CN = mx.google.com
issuer=C = US, O = Google Trust Services, CN = WR2
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 5003 bytes and written 441 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)