主页 / server / 问题

问题[ssl](server)

Martin Hope
Dennis
Asked: 2025-03-03 01:26:47 +0800 CST
  • 8

我有一个面向互联网的 Apache HTTPS 服务器 current.example.com。我想将该 Web 服务器重命名为 nextname.example.com。我还需要 current.example.com 在转换期间继续工作。这只是名称更改，并且将提供来自相同位置的相同内容。

我首先将 ServerAlias 添加到我的虚拟主机配置（HTTP 和 HTTPS）。这导致在访问 nextname.example.com 时出现“您的连接不是私密的”消息。我预料到了这种情况。

我知道一个（也许是唯一的？）解决方案是为 nextname 创建一个新证书，并创建一个新的 VirtualHost 配置。

但我希望有另一种解决方案。

此外，我意识到新的私钥不是强制性的，但可能建议这样做，因为我们已经需要一个新的证书。

有没有办法配置，以便两个虚拟服务器都可以使用/共享证书，或者是否需要新证书才能保留旧名称？

ssl
Martin Hope
Simon
Asked: 2025-02-28 12:38:49 +0800 CST
  • 5

我有一个虚拟主机，它通过 SSL 将非 www 重定向到 www：

<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 >

我是否需要在第一个仅执行重定向的 vhost 块中包含 SSL 配置和证书？如果我省略第一个 vhost 块中的 SSL 配置，重定向和站点仍能正常工作，那么为什么我需要将 SSL 证书放在第一个 vhost 块中？

ssl
Martin Hope
Kris Rice
Asked: 2025-01-27 02:01:50 +0800 CST
  • 5

我有一个使用 https 的 Scala+AKKA 网络服务器，以及一个使用 ssl 的 React+NextUI 网络应用。实际的服务器操作系统运行 nginx 并将调用适当地重定向到 next 或 Scala 网络服务器。

我想了解，我是否只为 nginx 生成 SSL 证书并将它们用于其后面的其他应用程序，还是它们都需要单独的证书？

如果有人能解释这个过程那就太好了，SSL 对我来说很新。

编辑：

我正在使用 javascriptcrypt模块，因此我必须使用 https 启动 Next。我别无选择，因为没有 ssl 连接，crypt 将无法工作。因此，仅使用 https 配置 sslnginx并让它以 http 形式传递给 next 不是一个选项

ssl
Martin Hope
Shadur-don't-feed-the-AI
Asked: 2025-01-22 19:07:16 +0800 CST
  • 5

我正在设置 haproxy 作为互联网和在其他隔离的 k8s 集群中运行的多个服务之间的中介。

我已经通过纯 http 成功测试了与后端的连接，但是现在我正在尝试处理那里的 SSL 组件，并且出于某种原因，无论我尝试什么，我都会在日志中收到以下内容：

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)

尝试通过openssl s_client以下方式进行故障排除（IP 地址和 DNS 名称已更改以保护有罪者）：

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)

haproxy 配置文件如下：

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

我确信我遗漏了一些非常简单且明显的东西，但我不知道是什么。任何帮助都将不胜感激。

ssl
Martin Hope
glossy
Asked: 2025-01-03 05:41:40 +0800 CST
  • 5

某些网站无法通过我的 VPS 发出 HTTP 请求。

例如， https: //openvpn.net请求失败：

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

额外的低级请求：

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

该 VPS 已通过 apt-updated 和 apt-upgraded，具有最新的 openssl：

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)

为了诊断该问题，我在本地安装了 Linux 并请求“有故障”的网站：

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

它有相同的软件：

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)

我的托管服务提供商写道服务器阻止了请求。

openssl 配置正确吗或者错误吗？

ssl
Martin Hope
Androz2091
Asked: 2024-11-15 17:51:43 +0800 CST
  • 5

我的域名 androz2091.fr 指向单节点 kubernetes 集群。Caddy 安装在节点上（在主机上，而不是 k8s 内部），并使用集群 DNS 重定向到正确的服务。

这是我的Caddyfile。这是我的集群文档。

不幸的是，访问我的域名时每 30 到 50 个请求就会出现此错误：

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.

我应该从哪里开始寻找问题？

我不知道如何调试它（它甚至没有出现在每个请求中），也不知道我的集群的哪个部分可能有问题。如果需要，我可以提供更多信息。

ssl
Martin Hope
Ravexina
Asked: 2024-10-21 04:43:49 +0800 CST
  • 6

我在 PostgreSQL 数据库上启用了 SSL，并使用pg_hba.conf以下行强制执行它：

hostssl all all 0.0.0.0/0 md5

从 PostgreSQL 连接日志和通过 tcpdump 捕获的网络流量来看，似乎正在建立 SSL 连接：

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)

然而，由于 Dovecot 和 PostgreSQL 运行在不同的机器上，并且证书及其 CA 在 Dovecot 机器上不受信任，我预计连接到 PostgreSQL 的 Dovecot 会标记自签名证书的问题，但没有出现任何投诉。这让我相信证书没有得到适当的验证，使连接容易受到 MITM（中间人）等攻击。

我是否缺少额外的配置或步骤来强制执行证书验证？如何确保连接安全并且证书得到正确验证？

ssl
Martin Hope
gkuenning
Asked: 2024-10-09 00:38:55 +0800 CST
  • 5

我运营一个科学网站，称为 site.org，它在三个位置都有镜像，所有镜像都在 DNS 中列为 site.org，以便客户端可以随机选择特定镜像。各个镜像为 server1.site.org 等。LetsEncrypt 证书涵盖 site.org 以及镜像名称。所有镜像都在捐赠带宽的大学内；我自己没有资金支付带宽费用。

一所大学 univ.edu 最近决定，为了“安全控制 https 通信”（他们的话），其网络内的所有站点都应使用 *.univ.edu 通配符证书。他们的实施方法是，在防火墙处，当他们看到端口 443 连接时，他们会拦截 SSL 握手并替换自己的证书。我的服务器从未看到证书握手。客户端浏览器看到 *.univ.edu 证书并拒绝它，因为它不涵盖 site.org。我要求将我的服务器的 IP 列入白名单以进行直通，他们说这样做“不可能”。

在我看来，用他们的证书替换我的证书就像是中间人攻击。公平地说，我不知道他们是否真的坐在那里监控流量，但我没有看到任何可以阻止他们这样做的东西。我不在乎出于个人目的的监控（网站上的所有内容都是公开的），但在我看来，这似乎是一个坏主意，尽管这让他们更容易管理 univ.edu 内部网站的证书。

那么：大型组织使用 AITM 方法管理证书是否正常？这真的只是因为他们想监视所有（传入，但不包括传出）连接吗？有没有我还没有想到的为什么这是一个坏主意的原因？

从根本上说，我正在寻找强有力的论据来说服他们改变立场。如果他们不让步，我担心我将不得不关闭镜像，这对我的用户来说会很遗憾，因为该镜像到其所在大陆的带宽要好得多。（不过，如果有其他建议，我将不胜感激！）

ssl
Martin Hope
HowardCodes
Asked: 2024-07-23 09:47:05 +0800 CST
  • 5

我有一个 cPanel 服务器，其中我编写了一个带有反向代理的包含配置文件，以将其指向服务器上托管的反应应用程序。

以下是一个例子：

 ServerName my.website

ProxyRequests off

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

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

我的服务器使用 Let's Encrypt AutoSSL 来保护域，但配置文件导致重定向问题，阻止 AutoSSL 保护域。我尝试了各种豁免来绕过 DCV 文件，但到目前为止都没有成功。我该如何编写它，以便 AutoSSL 继续保护我的域，即使有反向代理。

ssl
Martin Hope
Sean W.
Asked: 2024-07-16 23:18:59 +0800 CST
  • 12

我是 的作者checkdmarc，这是一款用于检查 DMARC 和其他电子邮件安全标准的开源 CLI 工具。其中一项检查涉及测试域MX记录中列出的邮件服务器是否支持 TLS。我发现在许多情况下，域的 MX 记录中列出的主机名与该服务器使用的证书的备用名称值不匹配CN。这会导致与这些主机的 TLS 连接因主机名不匹配而失败。

例如，MX 记录为gmail.com：

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.

然而，快速检查证书gmail-smtp-in.l.google.com显示，该主机提供的证书的 CN 是mx.google.com。我该如何解释这一点？邮件客户端是否只是忽略了 MX 服务器上的主机名匹配？这似乎很疯狂！

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)
ssl