Score:1

Getting AH02032 using TLSv1.2 despite identical SNI server name and Hostname, but SNI has the port number attached. No error in test env. with TLSv1.3

pl flag

Getting the the error message below despite identical Hostnames. What I don't understand, why the Hostname provided via SNI has the port number attached even though, according to Hostname specification, the colon and port number is not listed as part of the Hostname definition and the OpenSSL SNI extension treats the server name as Hostname. Is this a parsing error in Apache (and Wireshark)?

A tcp dump from a Debian client viewed with Wireshark lists during client hello and TLSv1.2 under SNI extension:

Server Name Type: Host_Name (0) and Server Name: MyHostname:443

While the client would allow TLSv1.3, TLSv1.2 seems to be mandated by the server during Client Hello.

The request is made using OpenSSL 3.07 cmp

Error Message: AH02032: Hostname MyHostname:443 provided via SNI and Hostname MyHostname provided via HTTP have no compatible SSL setup uri="path"

I would expect that when the package is parsed by Apache/SNI, the server name is taken without port and compared with the host name in the http header and be recognized as identical.

In a similar, but not identical to production environment, when TLSv1.3 is used, the error is not occurring with otherwise identical client settings.

(I don't have access to the Apache server which is part of a web application firewall.)

Amendment:

cmd: bin/openssl cmp -config etc/openssl.cnf -cmd ir -section cmp-init -ref [ref] -secret pass:[pass]-certout ssl/PKIstore/[store.pem] -newkey ssl/PKIstore/[new.key] -subject [SUBJECT DN] -implicit_confirm

openssl.cnf [default] [cmp] [cmp-init] prompt = no recipient = [ca-dn] path = [path] tls_host = MyHostname tls_used = yes server = MyHostname:443 path = [default path] trusted = [trusted.pem] cacertsout = [capubs.pem]

Note: The values for server, tls_host, and tls_used are defined in a opensssl.cfg file.

After further investigating the packet:

Whatever is given as server = [value] value ends up as Server Name in the server_name extension. And the length value includes the length of prefix https:// prefix or the port :443 if given as server value. [prefix][server_value][:port]

If either prefix or suffix are used, the server name does not matches the server name in the host header. If only server is given, the request is send to the default port 80, even if tls_used is set to yes.

Since the SNI server Name Type is host_name, I would expect, that it should not contains the protocol prefix nor the port.

Steffen Ullrich avatar
se flag
*"What I don't understand, why the Hostname provided via SNI has the port number attached even though"* - the request is done by the client. Likely the client is broken or used in a broken way. Not enough is known about the client though to help. *"The request is made using OpenSSL 3.07 cmp"* - this is not sufficient information. Please provide the exact command line you are using.
daniel buettiker avatar
pl flag
Thanks for your comment. Added command and configfile as requested, plus further insights.
Steffen Ullrich avatar
se flag
*"I would expect that when the package is parsed by Apache/SNI, the server name is taken without port and compared with the host name in the http header and be recognized as identical."* - No, the server_name field is not supposed to contain the port in the first place. It is also not supposed to be used for IP addresses, only for hostnames.
Steffen Ullrich avatar
se flag
*"server = MyHostname:443"* - why don't you simply use `https://MyHostname` as server, i.e. without port?
daniel buettiker avatar
pl flag
https:// MyHostname results in SNI Server Name https://MyHostname as explained above. Omitting https:// and :443 results in openssl cmp sending the request to MyHostname:80 even when tls_use = yes.
Score:1
se flag

This looks like a bug in OpenSSL to me and I've filed it as such: https://github.com/openssl/openssl/issues/20031

daniel buettiker avatar
pl flag
That's what I was thinking too. Thanks for confirming it and for the bug report!
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.