Follow this article
Implementing mTLS Between Two Apps Using ASP.NET
Guidance is requested on implementing mTLS between two applications using ASP.NET MVC in C#. or any .net code. The setup will involve a handshake between the server app and client app, developed in a localhost environment, utilizing OpenSSL or another tool for self-signed certificates.Once the proof of concept is successful, the intention is to migrate the solution to Azure App Services. Thank you.
Developer technologies | ASP.NET | ASP.NET Core
Developer technologies | ASP.NET | ASP.NET API
Developer technologies | ASP.NET | Other
2 answers
Sort by: Most helpful
-
Bruce (SqlWork.com) 79,101 Reputation points Volunteer Moderator
2025-01-08T16:22:28.95+00:00 -
Raymond Huynh (WICLOUD CORPORATION) 620 Reputation points Microsoft External Staff
2025-07-25T08:27:23.2266667+00:00 Hi @Abdul Baba Syed ,
After thoroughly reviewing all the answers and your latest concern, I’d like to address your question regarding the certificate validation warnings you’re seeing in Kudu.
Certificate validation failed, subject was CN=clientmtls-f9bsckaye2aqahda.canadacentral-01.azurewebsites.net, O=Internet Widgits Pty Ltd, S=Some-State, C=AU. PartialChain A certificate chain could not be built to a trusted root authority., RevocationStatusUnknown The revocation function was unable to check revocation for the certificate., OfflineRevocation The revocation function was unable to check revocation because the revocation server was offline.
What’s happening:
These warnings are common when using self-signed certificates or certificates not issued by a trusted public Certificate Authority (CA). The server is attempting to validate the client certificate’s trust chain and check for revocation, but:
- The certificate chain cannot be built to a trusted root (because it’s self-signed or the root isn’t in the trusted store).
- Revocation checks cannot be completed (often because the revocation server isn’t available for self-signed/test certs).
Should you ignore these?
For a proof of concept (POC) or development environment using self-signed certificates, these warnings are expected and can generally be ignored, as long as you are explicitly validating the certificate thumbprint (as you are in your code).
However, in production, you should use certificates issued by a trusted CA, and the server should be able to build a full trust chain and check revocation status.
Alternative approach for development:
If you want to suppress these warnings in development, you can:
- Continue using your thumbprint validation logic, which is a practical workaround for self-signed certs.
- Optionally, configure your server to relax certificate validation for development (not recommended for production).
For production:
- Use certificates from a trusted CA.
- Ensure the server can access revocation lists (CRL/OCSP).
- Remove any custom validation callbacks that bypass security checks.
You can safely ignore these warnings for your current POC with self-signed certs, since you’re validating the thumbprint yourself. Just remember to switch to proper CA-issued certificates and full validation when you move to production.
If you have any more questions, feel free to ask!