I use the same certificate both for client and service authentication on Wcf with message security. Does it cause any serious vulnerability?
You don't want to have the full certification on both the server and client for security reasons. Have a look at this Server / Client Certs
Related
In our platform, the client will generate their own self-signed certificate. We will then validate the certificate external from the nginx. I use optional_no_ca and not verify the client with a trusted CA. I perform verification on the server side after nginx
I am now building the production environment with API Gateway and ALB. However, I do not know the equivalent of optional_no_ca. I want the client to verify the server cert but the client certificate should pass through to the server for some application checks.
In the TLS handshake process, the Certificate Verify message will follow the Client Key Exchange message after the server requested a client certificate. The Certificate Verify contains a digital signature computed over all previous handshake messages including the type and length fields of the handshake messages. This process allows the client to prove that it owns the private key of the client certificate it sends to the server.
The idea came from a practical problem. There is an mTLS enabled server that conducts different action policies based on the client certificate received, for example, different welcome pages for different client certificates. If a layer-7 reverse proxy service like the load balancer is placed in front of the proxied server which also requires decrypting the TLS traffic. The proxied server can only get the client certificate information from the HTTP header (for example, set proxy_set_header with $ssl_client_cert variable in NGINX) which requires modifying the logic of the server.
A simple but very troublesome solution is the reverse proxy service stores all the client certificates and their private keys. The reverse proxy service will use the same client certificate it received during the mTLS handshake process to establish the mTLS connection with the proxied server.
Since the reverse proxy service can choose whether to trust the client or not with its own implementation, it is possible to forge the Certificate Verify message by asking the client to send a second Certificate Verify signature when the proxied server needs the reverse proxy service to do so (I know it's like a man-in-the-middle attack)?
Is it possible, in general, for a server to require both client certificate authentication and BASIC authentication?
For example, an intranet site of some sort, which requires :
The machine to have a specific certificate installed (client cert authentication), AND
A valid user to log in (basic authentication)
NOTE: this question isn't about a server supporting one or the other, but both together (as in the requester must authenticate both ways)
Yes, it is possible to have both. The client certificate will be verified during the TLS handshake while basic authentication will be done at the HTTP level, i.e. inside the TLS connection after the TLS handshake is done and the client certificate checked.
I am developing an application using IOS/Andriod/Angularjs for client site and Nodejs for server site.
I want encrypt file transfer between client and server for security.
For file transfer between a client and server use HTTPS (TLS 1.2). Everything but the address portion of the URL will be encrypted.
To avoid any MITM attacks you can pin the server certificate in the client.
You can do no better security wise than using HTTPS.
Can client certificates be used for authentication without HTTPS, only over HTTP on Windows IIS platform with ASP.NET ?
I need to authenticate a client using a digital certificate and i can't use HTTPS.
No you can't, at least if the client is a web-browser. Moreover, it doesn't have any sense.