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.
Related
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'm confused on how Self-signed certificate works.
Our application will connect to a server to get some info via SSL or https. This mean we are the client. The server is asking us to provide the Self-signed certificate. I created a RSA Key pair and a self-signed certificate.. What cert or key will provide to them? The public key and the self-signed certificate? and do we expect certificate from them?
What cert or key will provide to them?
Only the self-signed certificate should be provided. The private key should be kept private (hence the name).
... and do we expect certificate from them?
This depends if they also use self-signed certificates at their end or if a publicly trusted CA has issued the certificate. In the first case they need to provide the certificate, in the latter case your client just needs to trust the common publicly trusted CA (i.e. what the browsers do).
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
We have a XMPP server using SSL certificates (for both the server and the clients).
We use a self-signed CA to sign those certificates. Now we want to stop using that self-signed CA, but we have no idea how to replace those certificates to ones signed by an authority like Digicert or GlobalSign, since we don't know what to buy to do the same we usually do (we usually just create a public key, then a request and we sign it using the self-signed CA, and then voila, we have a certificate ready for the client to use)
Any ideas?
Thanks a lot.
we usually just create a public key, then a request and we sign it using the self-signed CA, and then voila, we have a certificate ready for the client to use)
The process is the same as for a Certificate Authority, with the difference you probably have to pay for the certificate
generate a key pair,private and public. (Not only the public)
Generate a Certificate Signing Request including the public key, some data about the certificate as Common Name, and sign it with the private key.
Send the CSR to the Certificate Authority
The CA validates the CSR, builds the certificate and signs it with its private key
Finally the CA sends you the certificate
I am trying to set up 2 way ssl mutual authentication for my web application. I currently haven't set up my client and am testing my web service through my browser.
I created a client certificate using the keychain tool on my mac and import the certificate.p12 file in Firefox. I also have a certificate.cert file. From my understanding I need to add this cert file in my servers truststore.
For that I need to using the following command:
keytool -import -trustcacerts -alias <hostname of DP> -file <your file.crt> -keystore <truststorefile>
However what do I add as the hostname of my system? What will the browser show the hostname as to my webserver?
First if you have client cert(s) issued by either a well-known CA (like Verisign, GoDaddy, etc) or a locally-trusted one (like your employer), you don't have to do anything. The client will simply present the cert with a chain that leads to the already-trusted CA.
If you have issued client certs from your own CA, you should add the CA (root) cert only to the server truststore. Then all client certs issued by that CA will be validated without further effort. If you make the CA cert long-lived, as is the usual practice, you can even renew and/or replace client certs with no effort on the server. And you can automatically revoke them if you set up CRL distribution and/or OCSP, although DIY CAs don't always want to go to that effort.
If you have created a self-signed client cert, then and only then you need to add that specific cert to the server truststore. Although SSL/TLS server certs must be identified by the hostname(s) of the server, client certs are not required to, and CA certs (which are the certs usually in your truststore by default) never have a hostname as the Subject (although some extensions usually contain URLs that contain hostnames). Codesigning certs also don't need to use a hostname.
The alias of a cert entry in a Java truststore does not need to be the hostname; it only needs to be unique, although it should be mnemonic of the subject of the cert. If for example your client certs are for users named Alice and Bob (or more likely their PCs or whatever devices) you can just use alice and bob as the aliases.