HTTP 401 with Auth Header and TLS

UAA
1

We are currently observing a behavior where a client certificate is transmitted both via the TLS handshake and additionally within the HTTP header (“Authorization: Cert …”). The TLS connection itself is successfully established, but the server responds with HTTP 401, indicating that a specific extension within the certificate cannot be read (Role “service”).

This raises the following question:

Is there any server-side logic that performs a validation or comparison between the client certificate presented during the TLS handshake and the certificate provided in the HTTP header? Specifically, is it expected that both certificates are identical or have a defined relationship (e.g., matching fingerprint, same certificate chain, specific issuer, etc.)?

If such a validation exists, what are the exact requirements for the certificate in the HTTP header in relation to the TLS client certificate?

When we use “trustAllCerts” for testing then there are no errors.

Thanks :slight_smile:

2

Some background information:
We use push-notification-service 3.2.1 which has a dependency to UAA 9.3.0.
In the old release (2.x) with UAA 8.x we had no problems.

Everything works fine with the current release when using the UAARestClientFactory connectors, but a customer connects to our NotificationCenter using plain Java (TLS 1.3) and then we get this error.

3

Issue resolved by A12-17908