We have a Java based application which connects to few servers over https.
The self signed certificates of these servers are added to client trust store to ensure https connections work.
Here is the scenario in question :
Server has a self signed certificate C1 with Public Key Pub1. This certificate is added to client trust store and connection works fine.
A new self signed certificate is generated on Server say C2 which has same public key as C1. i.e C2 has a different Serial Number, thumbprint, validaty dates but has the same public key as certificate C1.
Though C2 is NOT added to client trust store, the connection between client and server is working.
So it appears that X509TrustManager/X509ExtendedTrustManager checkServerTrusted implementation is only doing a public key match.
Same scenario tested with browser :
When server's self signed certificate C1 is NOT added to browser certificate store, Security exception is raised by browser. In case of Firefox(add server exception) and for Chrome(add the self signed server cert to trust store).
Browser does not throw any security exception now.
As explained before, when server changes to certificate C2 which has same public key as C1 (which is added to browser), browser still raises security exception.
So effectively there is a difference in Java v/s Browser trust behavior.
Related
Say I have a flutter app and an intranet server. The flutter client will try to talk to the server in TLS. I understood that we can generate a self signed certificate in server and I can have flutter client app load the certificate to talk to the server. I am thinking that if I store that certificate in asset, would that be secure ?
Seems that if someone got the certificate from asset, they can then talk to the server. Is that true ? If that is true that it seems that self certified certificate is not very secure.
Certificates are public, you're storing a copy of your self-signed certificate locally for your TLS client to trust it, as it'll only trust the system CAs by default. So no, nothing will be compromised if you store your certificate client-side.
What you shouldn't store client-side are private keys, they typically start with
-----BEGIN PRIVATE KEY-----.
I'm trying to call open banking production endpoint but It keeps kicking me out as I believe root certificate for MTLS is not picking up from the certificate store. How does postman pick the correct certificate from the certificate store?
Following is what my sandbox request looks like and it's working just fine as the certificate is getting from the certificate store.
But for production I get;
Error: write EPROTO 1316197336:error:10000410:SSL
routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE:../../third_party/boringssl/src/ssl/tls_record.cc:587:SSL
alert number 40
When you uploading a certificate to your certificate store, is there any additional setup you have to do?
In order to use client mTLS certificates in Postman you need to configure them for each particular domain through Postman settings.
So you need to open Postman Settings -> select Certificates tab -> press Add Certificated (under Client Certificates) -> Provide Host you are connecting to as well as your certificate file and private key for the certificate (or alternatively you could use a PFX file). Also remember to provide a Passphrase from your private key, in case you use one.
And for another host you would be able to use another client certificate, which is handy.
Good day,
My web application need to connect to IBM third party to get some response. Thus, IBM give me a .p12 file which contain of client certificate.
At first I import this .p12 file into my existing CellDefaultKeyStore, and it will hit certificate chain error.
com.ibm.jsse2.util.j: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:
java.security.cert.CertPathValidatorException: The certificate issued by xxx is not trusted; internal cause is:
java.security.cert.CertPathValidatorException: Certificate chaining error
Then I go import this .p12 file into NodeDefaultKeyStore, and surprisingly its work. My application able to call to the third party and get reponse code 200.
I am not understand how to explain to my client on this.
As my understanding, management scope in CellDefaultKeyStore is bigger because its in cell, NodeDefaultKeyStore should consider part of cell only, suppose CellDefaultKeyStore should work.
Anyone can advise on this?
Just to shortly explain few concepts:
CellDefaultTrustStore - is store for signer certificates, for the servers that you connect to, to be trusted. It is shared by all the nodes and servers by default
NodeDefaultKeyStore - is store for private certs, so the certs that are used for client authentication. Each node by default has its own store and private cert to authenticate.
CellDefaultKeyStore - is store for private certs associated with the cell. Used by deployment manager, not nodes serving apps. It is NOT used by federated nodes.
NodeDefaultSSLSettings - this manages SSL config for the given node, you can check it. By default it is using NodeDefaultKeyStore (not CellDefaultKeyStore), and CellDefaultTrustStore
But back to your question.
If you need to connect to some service using client certificate authentication, what you should do is:
create new keystore with cert from the p12 file
create new truststore with all signer certs required to connect to that service
create new SSL Config that will point to these stores
create Dynamic outbound endpoint SSL configuration settings, pointing to your ssl config, select correct client cert, and specify connection info in the form protocol,host,port
This configuration will be picked up when you will be doing outbound ssl connection that matches info you entered.
I was working on a sample TLS client/server program to perform certificate validation.
For a self signed certificate validation, these are the steps i followed.
#server side:
Generated a server key file serverkey.key
Generated a CSR certificate servercert.csr from the key file.
Digitally signed(using openssl x509 utility) the servercert.csr using a
generated rootCA.key and rootCA.cert. server certificate file servercert.cert
is generated.
Loaded the certificate file(servercert.cert) and key file(serverkey.key) using
SSL_CTX_use_certificate_file and SSL_CTX_use_PrivateKey openssl apis.
#client side:
Loaded the server ca-file --> rootCA.cert (which was manually copied to the
client) using the SSL_CTX_load_verify_locations api.
Using the SSL_get_verify_result() api validated the certificate that server
sends in the Certificate message.
The question that i have is that if i use a trusted CA(like godaddy) to sign a server CSR certificate, will the CA be providing its public key file (something similar to rootCA.cert) as well which was used for signing ?
By which i can load the same to the trusted list at client side using SSL_CTX_load_verify_locations api.
My intention is to keep the code unchanged regardless of being a self signed certificate or a valid CA provided certificate.
When (any) x509 certificate is generated, these things happen:
Private key is generated
Public key (associated with the private key mentioned above) is embedded in the new certificate (becomes an integral part of it)
The new certificate is signed using private key of the issuer (read: CA)
In order to verify the certificate integrity (to check if nobody tampered with it) - you need to verify the signature (created using issuer's private key - see 3)). To be able to do it you need to obtain (somehow) the issuer's public key. This key is embedded in the issuer's certificate (see 2)). Usually the trusted CAs' certificates are stored in so called trusted certificate store. In case of OpenSSL you specify this "store" by using SSL_CTX_load_verify_locations function (and a few other simmilar functions - consult OpenSSL documentation).
To summarize:
In your case the location pointed by SSL_CTX_load_verify_locations should contain your CA's certificate(s) - all of them - the whole certificate chain up to the self-signed root certificate. You can obtain all of the certificates in the chain from your CA (in your case GoDaddy).
I hope that helps.
If I can clarify anything more please ask.
When I login to my bank account using https, it's only a server side SSL authentication before I enter my login info. My browser does the server authentication based on the certificate info from the server during SSL session. I did not have to do any manual import of server certificate as a trusted cert into my browser. It just happens at runtime during SSL exchange.
On the other hand, I have also seen applications where one has to manually import the certificate (using keytool for e.g.) when you look into their install guide.
Question is: If the certificate info is exchanged in the beginning of SSL session, each side has enough info to authenticate the other side. Why would some apps require manual import of certs from each other between client and server. Be it either or both side authentication.
ADDITIONAL INFO based on the responses below:
I was referring the scenario where I was installing a commercial software based on client-server model with client side SSL authentication turned ON. I installed the server on machine A and 2 clients on different machines all in my private network. During install, server generates a self-signed certificate locally. So do the 2 clients. Once installation is complete, I was asked to copy the clients' certs to server machine and manually import them as trusted certs. Also, copy the server cert to client machines and do the import into their trusted store. They provided a wrapper tool on top of java keytool to perform the cert import. Why is this manual import necessary here? The client and server will anyway exchange certificate info during SSL handshake and perform the authentication. Again, these are self-signed certs and CA involved here.
Note that a certificate is signed by a certificate authority so it depends on which certificate authorities your browser trusts. If the Web server sends a certificate signed by a certificate authority that’s trusted by the browser/application and the certificate is valid, you shouldn’t get any warnings whatsoever.
On the other hand, if the browser receives a certificate from the Web server and it doesn’t trust the certificate authority that signed that certificate, the browser will take some action — at the very least, it should warn you about this. When you import a certificate from a Web site, you’re essentially telling your browser that you have decided to trust that certificate independently of who signed it.
Edit: The same reasoning applies: The keystore keeps a list of trusted certificate authorities and their corresponding certificates. The whole concept of PKI is to have a hierarchy of trusted CAs that emit signed certificates for other parties. If a certificate is self-signed, there’s no valid trust chain — how will Java know that the certificate hasn’t been forged by an attacker?
You’re assuming that a connection between a client and a Web server is implicitly trusted just because certificates are exchanged during the SSL handshake. What if a man in the middle poses as the Web server and, instead of sending the server certificate, sends his own certificate instead? How would clients know that the certificate received by the man in the middle is not to be trusted? If the certificate is signed by a trusted CA, or if the certificate has been manually added to the keystore as a trusted certificate, the client can check whether it should trust the certificate or not.
An SSL server's certificate has to be "vouched for" by a certificate authority (CA). Your browser (or other program) contains a list of CAs it trusts. If you're using a site that is not certified by one of the standard CAs, then you'd have to import its CA in order for the verification to succeed.
No legitimate site (especially for online banking) should require you to use an "alternative" CA. Only do this for sites where you're not sending super-sensitive data.