Now most of the SSL authentication is implemented directly through third-party libraries, suddenly I want to know the two-way authentication, the client and server exactly how to use the information inside their respective certificates for authentication. For example, we have client certificates and server certificates, and we have extracted the contents of both certificates. How can we determine whether the authentication is successful or not?
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
Linked to my question about client certificate authentication done the right way I was wondering whether I have to take the step to link a certificate to a user (active directory or local user) in order to have clientcertificate authentication to work as expected?
And is it necessary to disable all other authentication schemes (anonymous, windows) for clientcerticate authentication to happen?
See this question on the IIS forum:
This is what I would like to achieve:
A SSL-certificate for the URL itself (https://example.company.com). To my understanding this certificate does not have any connection whatsoever to client certificates.
Client certificates issued from my local CA and shared to trusted clients.
Some way of specifying which client certificates are allowed to connect to a specific IIS web site.
3 seems... complicated, to say the least. If I just set everything up and connect with a client certificate I have issued it works. The CA and the web server are on the same domain (if that matters), and I have added the root certificate from the CA to the trusted CAs on the web server. However, at this stage I have not told the web server which client certificates to accept, so my first guess was that it accepts all client certificates [chained to] any CA it trusts.
See also this question, which links to this site, which is dead.
It comes down to creating a "Certificate Trust List", or to mapping certificates to user accounts.
You can however implement a custom certificate validator in your service, how to do so is explained here.
I am somewhat confused as to how two-way SSL works. How does the client create its certificate to send to the server? Is it generated from the server and distributed to the client?
Also, what is the advantage of two-way SSL over one-way SSL?
Both certificates should exist prior to the connection. They're usually created by Certification Authorities (not necessarily the same). (There are alternative cases where verification can be done differently, but some verification will need to be made.)
The server certificate should be created by a CA that the client trusts (and following the naming conventions defined in RFC 6125).
The client certificate should be created by a CA that the server trusts.
It's up to each party to choose what it trusts.
There are online CA tools that will allow you to apply for a certificate within your browser and get it installed there once the CA has issued it. They need not be on the server that requests client-certificate authentication.
The certificate distribution and trust management is the role of the Public Key Infrastructure (PKI), implemented via the CAs. The SSL/TLS client and servers and then merely users of that PKI.
When the client connects to a server that requests client-certificate authentication, the server sends a list of CAs it's willing to accept as part of the client-certificate request. The client is then able to send its client certificate, if it wishes to and a suitable one is available.
The main advantages of client-certificate authentication are:
The private information (the private key) is never sent to the server. The client doesn't let its secret out at all during the authentication.
A server that doesn't know a user with that certificate can still authenticate that user, provided it trusts the CA that issued the certificate (and that the certificate is valid). This is very similar to the way passports are used: you may have never met a person showing you a passport, but because you trust the issuing authority, you're able to link the identity to the person.
You may be interested in Advantages of client certificates for client authentication? (on Security.SE).
What you call "Two-Way SSL" is usually called TLS/SSL with client certificate authentication.
In a "normal" TLS connection to example.com only the client verifies that it is indeed communicating with the server for example.com. The server doesn't know who the client is. If the server wants to authenticate the client the usual thing is to use passwords, so a client needs to send a user name and password to the server, but this happens inside the TLS connection as part of an inner protocol (e.g. HTTP) it's not part of the TLS protocol itself. The disadvantage is that you need a separate password for every site because you send the password to the server. So if you use the same password on for example PayPal and MyPonyForum then every time you log into MyPonyForum you send this password to the server of MyPonyForum so the operator of this server could intercept it and try it on PayPal and can issue payments in your name.
Client certificate authentication offers another way to authenticate the client in a TLS connection. In contrast to password login, client certificate authentication is specified as part of the TLS protocol. It works analogous to the way the client authenticates the server: The client generates a public private key pair and submits the public key to a trusted CA for signing. The CA returns a client certificate that can be used to authenticate the client. The client can now use the same certificate to authenticate to different servers (i.e. you could use the same certificate for PayPal and MyPonyForum without risking that it can be abused). The way it works is that after the server has sent its certificate it asks the client to provide a certificate too. Then some public key magic happens (if you want to know the details read RFC 5246) and now the client knows it communicates with the right server, the server knows it communicates with the right client and both have some common key material to encrypt and verify the connection.
In two way ssl the client asks for servers digital certificate and server ask for the same from the client. It is more secured as it is both ways, although its bit slow. Generally we dont follow it as the server doesnt care about the identity of the client, but a client needs to make sure about the integrity of server it is connecting to.
I have two WCF Services using WsHttpBinding with transport security mutual certificate authentication that are being hosted on the same windows server. Clients that can access one WCF service should not have access to the other WCF service. I need some help on configuring the client certificates on the windows host. The client certificates are signed by trusted CAs and the intermediate and root certificate chain is already installed on the the server. It seems like the service automatically relies on chain of trust and does not require the actual client certificates installed on the server at all before letting the client access the service - this is not the behavior I want. Can someone please tell me how I should be configuring these client certificates in order explicitly allow access to one service and not the other?
Thanks.
That has nothing to do with certificates themselves. When using mutual SSL authentication certificates are used only to authenticate client and the authentication is done outside of your application (this is difference to message security where you can create custom certificate validator). Once certificate is trusted client is automatically authenticated to anything on the server using certificates for authentication.
You are looking for authorization - the step where you define what can authenticated client do with your service. You can either hardcode your authorization logic into your service by using role based security or you can implement two custom ServiceAuthorizationManagers and assign each to single service.
Was wondering what the best practice for deploying a custom WCF - Security Token Service (STS) in a load balancing environment that uses signs and encrypts the token?
We're using Cirtix NetScaler to handle the load balancing and SSL termination (i.e. certificate is only installed on the NetScaler server). The STS has been specified to sign and encrypt the token via the SigningCertificateName and EncryptionCertificateName app settings. However the current web server configuration does not have a local certificate installed within it's certification store.
So my questions are:-
Do we need to worry about signing and encrypting the token if it's transferred over SSL?
Should we install the certificate on every web server or can we use the load balancer?
Can we use the same certificate on each web server or do we need to buy a certificate for each web server?
An STS which does not sign its tokens is not much use: without a signature, no relying party will be able to distinguish between a valid token issued by the STS and a token spoofed by someone with evil intent.
The certificate you install to support SSL is generally different to the STS's signing certificate. The latter identifies the Service, not the web server. So, by all means carry on installing the SSL certificate just on the load balancer. But you will need another certificate, representing the identity of the Service, installed (with its private key) on each machine which hosts the service, for use as the SigningCertificate. It should be the same certificate on each server (it's the same Service).
However, you typically don't need to buy such a certificate: you can issue your own - you just need to make sure each potential Relying Party is configured to recognise the certificate as a trusted STS, and also trusts the root issuer of the certificate (which will be either the certificate itself, if it is a self-signed certificate, or your root certificate, if you used a certificate server to issue it).