I need to setup client certificate authentication for a web app. I have a POC that works fine, except one thing: I can't figure out how to specify criteria for the client certificate (so that the browser only shows matching certificates when it prompts the user to pick one).
I know it's possible, because I've seen sites that did it, and the TLS RFC mention that the CertificateRequest can contain extensions "describing the parameters of the certificate being requested".
However, I can't find a way to do this with ASP.NET Core. I need to support this on IIS (for hosting in Azure App Service) and, if possible, on Kestrel (for local development).
Is it even possible?
EDIT: To be clear, I'm not asking how to validate the certificate once I received it. I'm asking how to specify which certificate I want (e.g. which CA issued it, etc.) during the TLS handshake.
Related
I'm working with an old legacy app at work that's written in ASP.NET 4. We recently started migrating to the cloud and we had to expose one of the endpoints so that our api gateway (Apigee) can call it. What is the correct way to restrict this endpoint so that it only allows calls from Apigee? I'm aware 2-way-ssl should solve this issue but that requires changes on the Apigee side and we don't have control over that. Is there something I can do on the API side to confirm that the certificate in the request is specifically from Apigee?
You're describing the need for what is sometimes called 'southbound' authentication. Specifically mutual-TLS sometimes called client authentication, as opposed to standard (or one-way) TLS where only the server is being authenticated by the calling client. You're right: mTLS (a.k.a., "two-way SSL") is one means to allow your back-end server to authenticate the calling Apigee-layer 'client'.
When you want client authentication via TLS (mTLS) you need to configure your back-end server endpoint to require mTLS at the time of the handshake, and to have stored in its Truststore the signing CA certificate of the client certificate you expect to see offered up by the calling client at time of connection. Done right, your server
requires mTLS and shuts down the handshake if the client won't
offer a client cert,
validates the client cert is authentic as being issued by a recognized signing CA (Truststore), and
is the actual client cert expected to be seen (e.g., by matching the expected distinguished name).
Here's an authoritative support-community article about doing all this, within Apigee: https://community.apigee.com/questions/63337/mutual-tls-between-client-to-edge-and-edge-to-back.html
I have .net core web application which runs using kestrel. There we have client certificate authorization, which works fine, but there is one issue, if user have some custom company related client certificates then browser offers big list of client certificates. But we accept only certain certificates.
So question is how to filter out client certificates based on root certificates. I haven't found any way to pass root certificate list to client, i can only validate them after user already selected certificate.
I have seen few websites where browser offers to select only compatible certificates, but as they use different technology it doesn't help much with .net core
I am trying to wrap my head around certificates and any help is appreciated. So far this is what I understand, please correct me if I am wrong.
When using the browser when I navigate to the https site the browser downloads the certificate(without the private key) and then continues to send the data over https?
I have come across some sites (especially when developing) that require you to install the certificate on the local machine before making a service call. What is the purpose here and how does it work?
I have also seen some scenarios where you need to install the certificate on the client machine for authentication purposes for example if you are using an email client, how does this work?
When using the browser when I navigate to the https site the browser downloads the certificate(without the private key) and then continues to send the data over https?
No, the browser and the server stablish a SSL/TLS secure channel with a symmetric encryption key. During the handshake process the server presents the https certificate and digitally signs some data with the private key as a proof of authenticity.
I have come across some sites (especially when developing) that require you to install the certificate on the local machine before making a service call. What is the purpose here and how does it work?
The client must trust the server certificate. Usually it has a list with the Certification Authorities for which certificates are accepted. For other certificates is needed to add them to the trust list. If not, the communication will be rejected
I have also seen some scenarios where you need to install the certificate on the client machine for authentication purposes for example if you are using an email client, how does this work?
Probably the same case as the previous one. Also the public part of the certificate of a user can be used to encrypt a message for him
I'm have an application deployed to salesforce on the force.com platform,
which I'm trying to configure a 2 way SSL for.
I.e.
I want that for each request sent to from SF to my server, a client certificate will be sent.
I did the necessary configurations on SF for the certificate to be sent, but I'm still getting 403.7 from the server, which means: forbidden, client certificate required.
I installed wireshark on the server, captured traffic to see the 2 way ssl handshake, and I'm trying to find in the server hello message where it tells the client the trusted CAs from which a client certificate should correspond, but I'm having difficulties finding it.
I suspect that's why the client does not send the certificate.
Can anyone point me to where in the server hello I should look? Or perhaps in another packet capture?
Thanks in advance.
Client Key Exchange record:
Here, the server sends its Certificate Request message and the client sends its Certificate message in response, but that message contains 0 certificates.
Typically, this happens when the client was unable to select a client certificate to use. Either it's not configured properly to make use of any certificate, or it can't find one that is issued by one of the acceptable CAs.
Look at the Certificate Request packet and check its certificate_authorities list. This is a list of the CA Distinguished Names (DNs) that the server is willing to accept.
One way or another, the client will need to find a client certificate with which it can build a chain towards of those DNs. In the simplest case, a client certificate issued by such a DN is available. Otherwise, the client could have to build a chain from a client cert to such a DN, it would need to have the necessary intermediate CA certificates to do so. (How this is done depends on the client's configuration mechanisms.)
If intermediate CA certificates are necessary and not available on the client side, you may need to configure your server to accept them and advertise them in the Certificate Request too.
Added a screenshot of the handshake captures. can you please point me to where I should be looking? –
See packet #31. It contains the Certificate Request. Also packet #33 contains the certificate from the client, so the reason is not the client does not send the certificate, but instead that the server either does not like the certificate because the validation failed or because the certificate is not sufficient as authorization for the requested resource. You might get more information from the servers log.
Not sure if this will help anyone else, but for our case of this issue everything was working when running locally in Visual Studio and in IIS, but when deployed to a real server, we were hitting a certificate issue during 2-way SSL as described above and verified in Wireshark.
Anyway, on that server we have also have a .NET 4.7.2 Console application which was calling the same API and everything was working fine.
But, our .NET 4.7.2 web API calls were failing. It appears that when the same code was running inside IIS the cert was not available during the SSL negotiation. (although it loaded fine)
Our solution at this point was to modify the following call to include the 3rd parameter.
certificate = new X509Certificate2(certificatepath, Password, X509KeyStorageFlags.MachineKeySet);
By default X509Certificate2 uses the UserKeySet option, so perhaps the application pool user or another thread in IIS (?) was having trouble accessing the cert for the negotiation.
Here are a couple of the related pages that I found useful during my research:
https://paulstovell.com/x509certificate2/
https://github.com/dotnet/runtime/issues/23437
I have an OAuth2 api exposed that runs over HTTPS. Since OAuth2 relies on the security of HTTPS (doesn't do any of it's own signing) I added a note in the developer docs encouraging developers to make sure they validate the ssl certificate in their client applications.
I noticed that some apps make the crt file publicly available or include it in their client: https://github.com/stripe/stripe-ruby/tree/master/lib/data
I assume this is just to make sure it is using the right certs (and not any system installed ones)? If so, is it a good idea to make this crt file publicly available to developers on your API page and what is an easy command/way to generate this file?
Thanks!
When one makes the certificate public this way, he encourages clients to do binary comparison of certificates, i.e. validate the certificate not in a way defined by corresponding standards by building a certificate chain and validating them) but simply by comparing the presented certificate with the one stored in the client.
This method is broken in several ways:
binary comparison doesn't let the client know that the certificate was revoked
with binary comparison the change of server certificate would require updating all clients so that new certificate would be included there. Failure to upgrade would mean impossibility to connect.
Consequently inclusion of the certificate and "straightforward" use of such certificate makes no sense, neither for server owners nor for clients.
The only case when binary comparison is applicable is when self-signed certificates are used (in which case building and validating a chain won't work). But self-signed certificates is a bad idea in any case (due to reasons listed above and some other reasons).