I have a VB.NET website configured in IIS to use client certificate authentication.
When a user opens website url, he gets a popup to choose the certificate. Once the user is on the web page there is a button, clicking this will make a SOAP request to a 3rd party.
Presently I am able to use a single certificate stored on the server to make the SOAP request (by attaching the certificate). Thus the same certificate is used irrespective of which user clicks on the button.
How do I attach the client certificate of the respective user to a SOAP request? Is this possible?
How do I attach the client certificate of the respective user to a SOAP request? Is this possible?
simply attaching the public certificate of client makes little sense. If you need to co-sign the SOAP request with client certificate, then you need to send unsigned SOAP request to client (say, client downloads the request from your web site), sign it, send to server, allow the server to co-sign the SOAP request and then submit this SOAP request to 3rd party.
You cannot upload client certificate to server in order to make SOAP signing on server. It is unsupported and vulnerable approach. Client certificate's private key (which is used to sign data) MUST NEVER leave client machine/device. If you need to sign anything with client certificate, signing operation must be performed on that client only.
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 an application that needs to communicate with a third-party SOAP/WCF API using a client certificate. I have tried everything on the web how to call SOAP/WCF API using a client certificate. But every time I am getting a client certificate authentication failed. Is there is a way to see whether I am passing the client certificate or not? Fiddler is not showing whether the client cert is sent with the request or not.
I'm working on an authentication method for my NodeJS API.
I'm using TLS certificates to verify the client connected to my API server.
My question is: can we have a way to authenticate the response back to the client? Can we use cert for this to(server to client)?
eg: When we call an API from our client we send the certificate with the request which is authenticated and if found valid the server sends the response, can we do it vice-versa, send a certificate in response and have the client validate the certificate.
The whole TLS protocol and the certificates are already built around this idea that you trust the server. I.e. the server during establishing of TLS connection provides a certificate that client can verify by checking if it trusts the CA that has issued the certificate.
Now while this is generally so, you can have libraries that allows to bypass this by not checking the certificate or checking but proceeding anyway, so you have to double check that is not the case. The browser does this automatically.
If you click on a green "Secure" button that is to the left in URL in Chrome e.g. you can click on "certificate" there and see the certificate that is provided by the server. If it's green, then it's trusted and all's good.
P.S. Neither the client not server sends the certificate the whole time back and forth with each request/response. They do it only once during establishing the connection that is called TLS handshake. It's relatively expensive process so you'd better keep the connection.
Does a web browser send client certificates to the web server on demand (means the web server is configured for client authentication and demands the client certificate) or does it just send all of the certificates that it has? If web browser sends client certificate on demand, then how does the web browser know which client certificate to sent to that particular web server?
I put my question on https://security.stackexchange.com/ and got this answer from #gowenfawr:
During the SSL handshake,
If the server requires a digital certificate for client authentication,
the server sends a "client certificate request" that includes a list of
the types of certificates supported and the Distinguished Names of
acceptable Certification Authorities (CAs).
(quote is from a reasonably lucid explanation of the SSL handshake by
IBM.)
The client then compares the certificates in its store against that
list to see if it has any signed by the CAs that the server listed. If
it finds one, it will send it, usually after prompting the user
whether they want to send it. Presumably if there were multiple
matches it would ask the user which to send (if any).
I have multiple sets of sensor networks that are sending data to a .net web api. Somehow, I need to secure some of the endpoints of the API (so that I can be certain that the information sent to the API really is from the sensors). Basic auth and SSL seems to be one way to go. The problem is that I'm having trouble understanding the SSL part.
As of now I have created a client certificate that is stored on the sensors, information of the certificate can be retrieved in the API by the Request.GetClientCertificate() method. Is this overkill when I just want to secure my Api with basic auth? That is, is the communication secure by just sending data over https without providing a certificate?
I do not need to use the certificate for authentication (since this is done by basic auth).
Basic authentication is about sending the user name and password in the HTTP authorization header as plain text (base64 encoded but not encrypted). For this reason, you need to use HTTPS with basic authn so that folks in the middle do not get to see the user name and password that a client sends.
When it comes to HTTPS, there is a server certificate and a client certificate. Server sends the server certificate to the client so that client can determine it is the right server it is connecting to. Similarly, a client can send a client certificate to the server so that a server can determine if an authentic client is talking to it.
The client certificate part is optional in HTTPS. So, you can use basic authentication without using the client certificate. If you use client certificate, it is already a credential and you need not use basic authentication, unless you want to use a two-factor authentication. TFA is an overkill or not - it is for you to decide.