Let's assume we have 2 CAs "ACA" using RSA and "BCA" ECC, both issuing TLS certificates for the server. ACA is trusted by most clients while BCA is only trusted by only a few.
While ACA is trusted, RSA always takes more time. So we'd want the cert signed by BCA to be preferred by all clients that trust BCA while the others would fall back to the ACA one.
As I know, configuring multiple certificates for a domain is possible. At least on nginx, but the client always uses the certificate I have put a as the second certificate entry in the snginx.conf configuration file of nginx.
So is it possible that the server handles delivering the EC certificate if possible, but the RSA one if the client does not trust the certificate?
The client does not provide any information which CA it trusts. This means that the server can not decide which certificate to serve based on the clients trust settings. The only information the server has to decide which of these certificates to use is to look at the ciphers offered by the client, i.e. use the ECC certificate if the client supports ECDSA ciphers and use the RSA certificate otherwise.
Related
I don't understand what is the actual need of having FabricTLSCA if we have PKI in place for secure communication. My assumption is that TLSCA is required for secure communication between different components. For example cert for my domain *.abc.com can be used using PKI than why Fabric TLSCA is required to give certificates.
You are not required to use the Fabric CA for issuing TLS certificates. You can use your own CA as well. You can even use 3rd party TLS/SSL certificate issuers such as Let's Encrypt, DigiCert, Verisign, etc as well. If you choose to use mutual TLS, you may want not want to use a public 3rd party service if you are looking to to added authentication, but generally speaking it is unnecessary to use mutual TLS in any case.
TLS CA is used for TLS communication between components. Communications are encrypted end to end via TLS so that they can not be disclosed. Certificates signed by TLS CA are valid during TLS handshake.
Regular MSP CA is used for authentication, membership... Signatures in Fabric are validated as the certificates used for signature are signed by MSP CA.
Both CAs can be the same. They can be different, too.
I am implementing mutual authentication between a single client hosted app (CLIENT) and my spring boot 2 application (SERVER). I understand the steps to be as follows:
The server generates a keystore and truststore. The keystore being used for storing the server's certificates and private key. The truststore used for storing other credentials (certificates from certificate authority (CA) or trusted client certificates).
A CSR is raised for the server which is then passed to a CA. The CA generates a signed certificate from the CSR. This is the installed in the server keystore.
The client (which has it's own keystore and truststore) provides their public key to the server. This is then installed in the server truststore.
When a https request is made from client to server:
The client makes a request to access a protected resource.
Server responds with their public certificate.
Client verifies that certificate (looks in truststore and checks if it signed by a trusted CA).
Client presents their public certificate to server.
Server then verifies certificate against their truststore.
Assuming verification success client is granted access to the protected resource.
So I have a few things which I'm a bit confused about...
Are the steps outlined above broadly correct?
How does the server verify the client certificate? (I think it looks at the truststore for that certificate but not sure what actually happens after that).
I've seen examples of the CA certificate being installed in the server truststore instead of the actual client's public certificate ~ is there a use case when this should or should not be done? For my use case I have been provided with a signed certificate from the client (third party). The CA who signed that is different from the CA who signed the server certificate.
Does this process actually authenticate the client i.e. this client can now have access to the servers protected resources but another client who might present a different certificate will not have access? (like a more secure method of providing a username and password)
Where does common name (CN) checking come into all of this? I note in Spring Boot X.509 you can derive a username from the CN and then use this to lookup the appropriate user details from the user details service.
If the client certificate gets compromised for whatever reasons is this managed by just removing it from the server's truststore?
Is there an advantage, in my scenario of using a trusted CA e.g. verisign to produce a client certificate over a self-signed one? i.e. the certificate is passed to me directly from the trusted third party, and then installed.
In respect to your first question, yes your outlined steps are correct! Here is the general mutualSSL flow with a graphical overview: (source)
A client requests access to a protected resource.
The server presents its certificate to the client.
The client verifies the server’s certificate.
If successful, the client sends its certificate to the server.
The server verifies the client’s credentials.
If successful, the server grants access to the protected resource requested by the client.
Your second question (How does the server verify the clients certificate?):
The server verifies the clients certificate with the help of the signature. The signature is usually a hash-value, build of the complete certificate. The hash-value is signed with the private key of a corresponding CA (certificate authority). The server verifies the signature of the client certificate with the help of the CA's public certificate.
Your third question (Servers truststore containing the clients public key/certificate or the corresponding CA certificate?):
If you use for example self-signed certificates, you probably have to import the clients public key/certificate directly into the servers truststore. If your client uses an CA signed certificate, it is appropriate for you server to store the CA public key/certificate only, because it is used to verify the clients certificate.
Your fourth question (Does this process actually authenticate the client): Yes! As you can see in the answer to your second question, the certificate is verified by checking the signature. The signature is a hash over the complete certificate. A standard X.509 contains information to identify the subject. By checking the signature the subject is authenticated. A standard X.509 certificate contains amongst other things e.g. this information:
Subject name, Subject Public Key Info, Public Key Algorithm, Issuer Unique Identifier (optional), ...
Your fifth question (Where comes CN checking?): The CN (common name) verification is executed during the certificate check. The CN identifies the valid hostname for the current certificate. It is limited to one entry. As an extension the SAN (subject alternative name) was introduced. A certificate can contain more than one SAN. The CN (and the SAN) entry is part of the certificate and is verified with the help of the certificates signature check.
Your sixth question (If the client certificate gets compromised for whatever reasons is this managed by just removing it from the server's truststore?): Therefore the CAs use so called revocation lists. If you are using for example self-signed certificates it would also be okay to just remove the compromised certificate entry from the servers truststore.
Your seventh question (Is there an advantage, in my scenario of using a trusted CA e.g. verisign to produce a client certificate over a self-signed one?): There exist a few advantages of using a CA signed certificate instead of self-signed ones.
The certificate and eventually the revocation is managed by the CA
The certificate is valid to every relying party of the public CA, e.g. Verisign
Most of the public CAs offer standardized ways of creating a certificate
How does the client ensure the ssl certificate that the server send is the true owner of the certificate? How does it prevent a hacker from cloning, for example, the google ssl certificate, and trick me that he is the google site during the handshaking? can the hacker clone the certificate and modify the domain or ip info from network packet to trick people?
An SSL certificate for e.g. www.google.com is signed by a 3rd party named a Certificate Authority (CA). In the case of google that 3rd party is currently "GeoTrust Global CA". Too look up who it is, you need to inspect the certificate (browsers typically will let you do that rather easily, but each has their own way)
That links the certificate with the name "www.google.com".
Your client(s) have a list of CAs they trust on your behalf. That list is either maintained by the vendor of your OS and/or by the creator of your client/browser.
So how does the client know it's talking to the right server ?
The certificate is signed by a CA it trusts, the certificate is for the name the client wants to connect to, and the server delivered proof it knows the corresponding secret key to the public key that's in the certificate.
A hacker who would copy a valid certificate from www.google.com and place it on their own machine would only have the public key and not have the private key.
A hacker who would try to get their certificate request signed by a reputable CA would get rejected because they cannot proof to own the google.com domain. And hence the name would not match.
A hacker who would sign their own certificate request, would fail as their self-built CA is not in the trusted list.
A hacker who would break into google's servers and copy the secret key somehow, could pass muster for a while, but once the folks at Google detect it, they would contact their CA and revoke the certificate.
Now this process is the weak point in most implementations as these revoked certificates are published by the CA as Certificate Revocation Lists (CRLs) or as an OCSP (Online Certificate Status Protocol) service, but clients typically take the shortcut and do not validate that a certificate has not been revoked.
I need to validate client as well as server's certificate.How can I do it at TCP level and at HTTP level? for Http I use cURL client library.OpenSSL is the SSL library.This has to be done through self signed certificates only.Which web server or http server I need to use which validates client's SSL certificate?
Since you are using self-signed certificates, you can configure that certificate as though it were the one and only authorized CA. If the peer presents that very certificate, it will be accepted because it appears in the list of CAs. If the peer presents any other certificate (or no certificate), it should be rejected.
You didn't say what programming language you are using with libcurl, but here's a pyCurl example for verifying the server:
req.setopt(pycurl.SSL_VERIFYPEER, 1)
req.setopt(pycurl.CAINFO, "/the/path/to/the/certificate/we/want/the/peer/to/use")
and of course the client wants to authenticate itself to the server:
req.setopt(pycurl.SSLCERT, "/the/certificate/the/client/will/present")
req.setopt(pycurl.SSLKEY, "/the/private/key/that/goes/with/it/in/PEM/format")
As for the server side, it's generally easy to configure as well, but it depends what web server software you're using.
EDIT: Elaboration as requested on "you can configure that certificate as though it were the one and only authorised CA".
Normally, a peer presents a certificate, and the local end validates it against a CA (or a list of CAs). The CA is a different certificate than the peer's certificate. The CA certificate has either directly or indirectly signed the peer's certificate.
When using a self-signed certificate, then the peer can present that certificate. The local end can pretend that the same certificate is a CA certificate. Because the certificate is signed by itself (by definition), it qualifies in this case as being signed by a valid CA... since a valid CA is itself!.
My question is about certificates specifically in ssl but I think the questions should apply to all certificates. I have included the SSL procedure for the sake of clarity.
In SSL this is what I understand the procedure is:
1)Client
sends supported crypto algorithms
sends client nonce
Server
chooses (and sends) a
symmetric algorithm
a public key algorithm
a MAC algorithm
sends it's certificate
sends server nonce
Client
verifies certificate
Extracts public key
Generates a pre-master secret key (pms)
encrypts with servers public key and sends
Client and Server
compute master secrete (MS) from PMS and nonces
PMS sliced to generate two encryption & two mac keys
Client
sends a mac of all handshakes (to ensure they were not previously modifide)
Server
sends a mac of all handshakes
Question
What stops a man in the middle attack from happening at step two? Why can't a man in the middle, say trudy, capture the certificate sent by the server and change the public key in it (to something it has the private key to).
I assume that the certificate is encrypted somehow.
However the server cannot encrypt the certificate because the client does not have the public key yet. When the server gets the key from an authority (like veri-sign) would the key be pre-encrypted using verisign's public key? I think this should work because all web browsers should have the public keys of most authorities.
No, the certificate is not encrypted. But it is signed by a certification authority (CA). Since those check the information included in the certificate (especially the URL to which the cert belongs), there shouldn't be a second valid certificate for a given URL.
The cert of the CA is checked against a trust store (e.g. in your browser). If this truststore is compromised, or if you trust not valid certificates, there is no protection against man in the middle attacks
Certificates are signed by some trusted authority, such as Verisign.
The certificates for these root authorities are built right into the browsers when you download them. You can view the root certificates in Firefox, for example, by going to tools-->options-->advanced-->encryption-->view certificates-->authorities.
If any one of these root-certificate authorities is compromised, however, you are right that a certificate could be forged, making a man-in-the-middle attack possible.
You actually pointed out a weak spot of PKI.
Say Trudy is in the middle of you and yourbank (bank.com). Trudy can change the public key at will at step 2 but the certificate's signature will be invalid. So Trudy has to find a way to generate the signature again. It's safe to say that the trusted CAs will not do this for him. So he has to sign with a fake CA, which is not trusted by your browser. This is still safe theoretically.
However, most browsers (especially IE 6) display a vague security warning and most people don't understand and just ignore, according to some tests.