PCI promotes a method that is inferior in terms of security to a redirect? Wow.

Partially solved: I have access to CA's root certificate and I am able to validate the certificate in JWS (openssl verify) as well set set is as "client certificate" on the server for mTLS. Still, the correct approach for JWS remains a mystery to me.

1. Actually, it is a brand new feature in Azure Application Gateway for full mTLS (docs.microsoft.com/en-us/azure/application-gateway/… / docs.microsoft.com/en-us/azure/application-gateway/… ) 2. "[JWS] implementations can vary a lot." - well, that explains a lot :) Is my approach correct? Question on the origin of a root cert public key still remains. 3. So I should expect that openssl.org/docs/man1.0.2/man1/openssl-verify.html characterizes a typical client cert validation on my http server?

@Philipp partially the first part yes, but not entirely

On first thought, that is a sensible answer. I was not aware this could be the case so I have omitted the fact that the another service is a physical machine where certificates cannot be updated remotely by design and nothing can be updated on their end (they, as an organization, can use their root cert though). Also, I don't really understand how in this scenario they could trust me but not any other web service that has a certificate signed with Let's Encrypt. I understand they want to remain in control whose certificates they sign. Should I update the question or this is irrelevant?

I understand this will not make it a disadvantage, at most both methods will be on par?