1

I would like to access my web site with Chromium browser (Version 124.0.6367.201 (Official Build) snap (64-bit)) but I face a fatal SSL error.

According to the wireshark dump, the error is due to a TLS/SSL handshake failure. Digging deeper, the client (Chromium) says it supports the following ciphers and signature algorithms in the Client Hello message:

Cipher Suites (16 suites) Cipher Suite: Reserved (GREASE) (0x3a3a) Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301) Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302) Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9) Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Signature Hash Algorithms (8 algorithms) Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) Signature Algorithm: rsa_pss_rsae_sha256 (0x0804) Signature Algorithm: rsa_pkcs1_sha256 (0x0401) Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) Signature Algorithm: rsa_pss_rsae_sha384 (0x0805) Signature Algorithm: rsa_pkcs1_sha384 (0x0501) Signature Algorithm: rsa_pss_rsae_sha512 (0x0806) Signature Algorithm: rsa_pkcs1_sha512 (0x0601)

On the server side, Apache2 is configured to accept all ciphers (mod_ssl.conf):

<IfModule mod_ssl.c> SSLRandomSeed startup builtin SSLRandomSeed startup file:/dev/urandom 512 SSLRandomSeed connect builtin SSLRandomSeed connect file:/dev/urandom 512 AddType application/x-x509-ca-cert .crt AddType application/x-pkcs7-crl .crl SSLPassPhraseDialog exec:/usr/share/apache2/ask-for-passphrase SSLSessionCache shmcb:${APACHE_RUN_DIR}/ssl_scache(512000) SSLSessionCacheTimeout 300 SSLCipherSuite ALL:!aNULL SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 </IfModule> 
<VirtualHost api.example.com:443> ServerName api.example.com DocumentRoot /srv/www/api SSLEngine on SSLCertificateFile /srv/ssl/api.example.com.crt SSLCertificateKeyFile /srv/ssl/api.example.com.key LogLevel debug ErrorLog /var/log/apache2/error.log CustomLog /var/log/apache2/access.log combined </VirtualHost>

The Apache2 SSL error logs are:

[ssl:info] [pid 31:tid 140284504107968] AH01914: Configuring server api.example.com:443 for SSL protocol [ssl:debug] [pid 31:tid 140284504107968] ssl_engine_init.c(1705): AH: Init: (api.example.com:443) mod_md support is unavailable. [ssl:debug] [pid 31:tid 140284504107968] ssl_engine_init.c(492): AH01893: Configuring TLS extension handling [ssl:debug] [pid 31:tid 140284504107968] ssl_util_ssl.c(470): AH02412: [api.example.com:443] Cert matches for name 'api.example.com' [...] [ssl:info] [pid 31:tid 140284504107968] AH02568: Certificate and private key api.example.com:443:0 configured from /srv/ssl/api.example.com.crt and /srv/ssl/api.example.com.key [ssl:info] [pid 32:tid 140284504107968] AH01914: Configuring server api.example.com:443 for SSL protocol [ssl:debug] [pid 32:tid 140284504107968] ssl_engine_init.c(1705): AH: Init: (api.example.com:443) mod_md support is unavailable. [ssl:debug] [pid 32:tid 140284504107968] ssl_engine_init.c(492): AH01893: Configuring TLS extension handling [ssl:debug] [pid 32:tid 140284504107968] ssl_util_ssl.c(470): AH02412: [api.example.com:443] Cert matches for name 'api.example.com' [...] [ssl:info] [pid 32:tid 140284504107968] AH02568: Certificate and private key api.example.com:443:0 configured from /srv/ssl/api.example.com.crt and /srv/ssl/api.example.com.key [mpm_event:notice] [pid 32:tid 140284504107968] AH00489: Apache/2.4.29 (Ubuntu) OpenSSL/1.1.1 configured -- resuming normal operations [core:notice] [pid 32:tid 140284504107968] AH00094: Command line: '/usr/sbin/apache2' [ssl:info] [pid 36:tid 140284314003200] [client 192.168.10.1:46406] AH01964: Connection to child 0 established (server api.example.com:443) [ssl:debug] [pid 36:tid 140284314003200] ssl_engine_kernel.c(2317): [client 192.168.10.1:46406] AH02043: SSL virtual host for servername api.example.com found [ssl:debug] [pid 36:tid 140284314003200] ssl_engine_kernel.c(2317): [client 192.168.10.1:46406] AH02043: SSL virtual host for servername api.example.com found [core:debug] [pid 36:tid 140284314003200] protocol.c(2372): [client 192.168.10.1:46406] AH03155: select protocol from , choices=h2,http/1.1 for server api.example.com [ssl:info] [pid 36:tid 140284314003200] [client 192.168.10.1:46406] AH02008: SSL library error 1 in handshake (server api.example.com:443) [ssl:info] [pid 36:tid 140284314003200] SSL Library Error: error:14201076:SSL routines:tls_choose_sigalg:no suitable signature algorithm

We clearly see that Apache cannot find any common cipher algorithm to complete the handshake and thus closes the connection ..

The weirdest thing is that this configuration works fine with FireFox. I noted that the FireFox client has two more ciphers in its list during the SSL handshake:

- Cipher Suite: Reserved (GREASE) (0x3a3a) + Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) + Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) + Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) + Signature Algorithm: rsa_pkcs1_sha1 (0x0201) + Signature Algorithm: ecdsa_sha1 (0x0203)

Has anyone succeeded to access a web site served by apache2 using a Chrome browser over SSL/TLS?

EDIT: The signature algorithm for both the CA and the server certificate is ecdsa-with-SHA256 and they both rely on secp521r1 for private key.

EDIT: I found out the reason why it does not work with Chrome. This is due to the algorithm used (secp521r1) which is not offered by Chrome during the Client Hello although this algorithm is safe to use. Changing the algorithm of the server certificate seems to be sufficient to solve the issue.

The reason why changing the server certificate only is sufficient remains a mystery. I would be grateful to anyone who can shade a light on this ..

Improve this question

1 Answer 1

Reset to default
4

We clearly see that Apache cannot find any common cipher algorithm ...

Not at all. We clearly see Apache (really OpenSSL) cannot find any suitable signature algorithm aka sigalg. That is completely different from a cipher suite used in TLS, which in turn is more than just a cipher algorithm, although for 1.3 it gets somewhat closer than previously.

You don't show the trace data for the sigalgs extension in the ClientHello -- or sigalgs_cert if present -- but my Windows Chrome 125 (which I doubt is different) offers sigalgs rsa_pkcs1 and rsa_pss_rsae (but not rsa_pss_pss) with sha256/384/512 and ecdsa with [p256_]sha256/[p384_]sha384 (the latter irrelevant if your cert is RSA), and sigalgs_cert is omitted making it implicitly the same as sigalgs. OTOH my Firefox ESR 115 additionally offers ecsa_[p521_]sha512 -- and rsa_pkcs1_sha1 and ecdsa_sha1 (with lowest priority, as TLS1.3 specifies they should be if used at all).

Thus the most likely problem is that your cert or some part of its chain is old or selfmade/corporate/etc and signed with SHA1 (which trusted public CAs stopped doing a decade ago) -- check that. The Chrome failure, but not the Firefox success, could also be caused if it or any part of its chain was a PSS-only key.

Improve this answer
0

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.