I have trust store which contains Symantec. I am trying to connect to server which is signed by VeriSign. I am getting ssl "No trusted certificate was found” during the handshake. Can it be because I don't have VeriSign CA in trust store?
I am using Axis framework with SSLConnectionSocketFactory. With openssl I see the VeriSign certificate chain on the server
My problem solved after adding the VeriSign CA to trust store.
Related
i builded an app running in console with Python. Then i made this app convert to exe. i wanna publish this app on the web. So i signed this app. But i see this problem:
This CA Root certificate is not trusted. Upload this certificate to the Trusted Root Certification Authorities store to be trusted.
From this warning i understand that i must my upload certificate to the Trusted Root Certification Authorities store. But i do not know it way.
My app certificate' s is:
https://www.digicert.com/support/tools/certificate-utility-for-windows
Who issued certificate:
http://127.0.0.1:5000/
Whom was issued certificate:
http://127.0.0.1:5000/
Signature algorithm:
sha256RSA
You're using self-signed certificate i.e. certificate is not issued from valid trusted Certificate Authority. If you want to publish the app for public, then you've to sign it by obtaining the certificate from valid trusted certificate authority (CA). In case, you want to manually share the app with the recipients, and they're aware of the possible risk factor then you can share the issuer certificates with them, and they've installed those into the windows trust store.
Just search for certmgr on windows and add the issuer certificates into Trusted Root Certification.
According to TLS connection definition, for example, as the client-side, I use keystore to store my private key and certificate, and use truststore to store some kinds of certs. On the server-side, that call it Youtube, it has a root certificate called Youtube.pem which is signed by Google.crt CA.
I know the truststore is to verify the 3rd party certificate during handshake
My question is what should my truststore actually store during handshake?
Youtube.pem (the CA signed certificate sent from 3rd part)
Google.crt (the CA certificate)
According to TLS connection definition, for example, as the client-side, I use keystore to store my private key and certificate, and use truststore to store some kinds of certs.
Yes, but you only need a keystore if you want to use client side authentication. Note that "keystore" and "truststore" indicate how the store is used, they can be of the same type (e.g. PKCS#12) and even the same file.
On the server-side, that call it Youtube, it has a root certificate called Youtube.pem which is signed by Google.crt CA.
No, YouTube is a service, it has a leaf or end-entity certificate. The root certificate is that of a third party CA. The end-entity certificate is usually signed by an intermediate CA certificate, and that is in turn signed by a self signed root certificate.
I know the truststore is to verify the 3rd party certificate during handshake
It is used to validate and verify the trust path from leaf certificate to a trust anchor in your truststore. The trust anchor is usually one of the root certificates stored in your truststore. The leaf certificate is indicated by the end entity / server, the intermediate certificates are usually sent by the server as well, but they could also be retrieved from a cache.
In the case of YouTube, the Google root CA is used, possibly using the GlobalSign root through a linked certificate if the Google root is not present in the trust store.
So your truststore should either contain the Google root certificate or the GlobalSign root for the connection to work in this example.
I am using OpenSSL program to generate my SSL self-signed certificate, created a CA certificate and a webserver certificate. The webserver certificate, I have signed it with the CA certificate. I created a keystore with Java's keytool to import webserver's certificate.
On the client side, I have imported the CA certificate inside client's Certificate Manager, under the "Trusted Root Certification Authorities".
In theory, is this way considered as a One way TLS or a Two way TLS communication?
Thank you so much for the help!
In TLS protocol by default the client validates servers authenticity, the server sends its certificate during the handshake and the client validates it with the CA certificate in its trust store. It is one way setup
For two way, during the handshake, the server also asks for certificate from client,it validates the certificate sent by the client with the CA certificate in its trust store. So if you want to use two way setup, you need to generate client CA certificate and client certificate(it will be signed by the client CA certificate), the same CA certificate you need to configure at server so that it(server) will be able to validate the client certificate it received during the handshake.
You can also decide to keep same CA certificate for both client and server certificates, making sure client and server certificates are signed by the same CA
I have to create an SSL connection between a client and a server. I've created a keypair and signed my public key with my private key. The server won't trust this so I need to get it signed by a CA. I presume that the server will trust a certificate which has been signed by the same CA as was used to sign its own certificate. How do I do the business of creating the signed certificate with keytool? Sorry if this is duplicated information on the Oracle website, but for some reason their pages keep breaking my internet browser.
knowledge so far is based on answer here
I presume that the server will trust a certificate which has been signed by the same CA as was used to sign its own certificate.
Correcting your assumption here: A system trusts various major Certificate Authorities (CA) by default (eg: GeoTrust, Entrust, OpenTrust, Verisign, etc...). When you get your CSR signed by any of these known CA's, the server will trust by default, not just by the CA that signed the server's certificate.
What you could do to test your SSL connection between the client and the server is to work with self-signed certificates.
I've created a keypair and signed my public key with my private key
You shouldn't be doing this as a client. The server is supposed to do this. If the server is working with self-signed certificates, they need to provide the client with that certificate, so that the clients can trust them to make the SSL connection.
As a server, you could use the keytool to create a self-signed certificate. When you are generating a keypair using keytool, it will ask you few attributes like commonName, organizationName, etc... using these attributes, the keytool will create a self-signed certificate and associate it with the private key. All you have to do is export this certificate using the keytool -exportcert command. Once you have done this part, you would use this certificate to secure the server.
Once the server is secured, the server should give or the client this certificate, because it is self-signed and the client's system will not trust it until you explicitly trust it. If the server has secured using a certificate signed by a CA, it need not provide the client with any certificate, because, if it is a known CA, it will already be trusted by the client system.
I'm having an issue calling an asmx webservice:
Could not establish secure channel for SSL/TLS with authority ...
When I go to the asmx url in a browser on the server (WIN2k12R2 fully patched as of 6 Sep 2016) making the requests I don't see any issue with the certificate. It's issued by COMODO RSA Extended Validation Secure Server CA (Intermediate Certification Authorities), which is issued by COMODO RSA Certification Authority (Intermediate Certification Authorities), which is issued by AddTrust External CA Root (Trusted Root Certification Authorities) - all report ok.
The time on the server (UTC) is synced with 3.europe.pool.ntp.org
I'm using the proxy that was built by Visual Studio.
I've moved the Intermediate COMODO certs to the Trusted Root Certification Authorities and no longer encountered the error - does this seem like a valid solution? It appears to have solved the problem, but I don't understand why.