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
Related
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 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 have a self signed CA which has 1024 bit key length. Is it possible to sign a server certificate with longer key length (2048 bit) using this CA? I want to sign a server certificate and configure that for Active Directory service.
I'm able to do this using bouncy castle. My concern is about
1) Is this a good idea?
2) How would the certificate trust be established? Would that be okay.
Yes, you can use your 1024-bit RSA private key to sign a certificate for a server that is using a 2048-bit key. The length, and even the type, of the key in the certificate you're signing (the server's certificate) has no relation to the key you're using to do the signing. For example, you could have your 1024-bit RSA private key sign a certificate for a server using a 256-bit EC key if you wanted.
(Technically, you aren't signing the certificate itself, but a hash of the certificate. See this question and answer for details. But conceptually, you can think of it as "signing the certificate".)
Trust is established the same as with any other certificate chain:
Your client contains your CA's 1024-bit public key in its trust store.
Your client connects to a server, which sends its certificate, signed by your CA.
Your client sees that the certificate is signed by a CA in your trust store, so it verifies the CA's signature on the server's certificate using the CA's public key in the client's trust store.
The signature matches, so the client trusts the server's certificate.
If I understand SSL/TLS correctly in server only authentication, After the handshake, the server sends the client it's public key and a digitally signed certificate signed by a CA. If the client has this CA's public key, it can decrypt the certificate and establish trust with the server. If it does not trust the CA, then the communication stops. In 2 way SSL where the client needs to authenticate back to the server, after the client receives the public key and the digitally signed cert then the client will send the server over it's public key and a digitally signed cert. The server will check to see if it has a public key for the client's cert and if it does it can establish trust with the client. I am setting up mutual authentication [ 2 way ssl] on a weblogic server [in this case the client, calling outbound to a web service] and the third party sent me a digitally signed cert and a certificate chain. Why do I need these. Isn't this what the server replies with after the handshake?
the server sends the client it's public key and a digitally signed certificate signed by a CA.
The certificate contains the public key. The key is not sent extra.
If the client has this CA's public key, it can decrypt the certificate
The certificate is not encrypted, it is signed by the CA. Thus no decryption is done but the client can verify this signature if the client has the CA's certificate (and thus its public key). But usually the certificate is not signed directly by a CA trusted by the browser but there are intermediate certificates. In this case the server will not only send the servers certificate but also all intermediate certificates which are needed to build the trust chain.
then the client will send the server over it's public key and a digitally signed cert.
Again, the public key is part of the certificate.
the third party sent me a digitally signed cert and a certificate chain. Why do I need these.
The first certificate is the client certificate. The chain certificates are needed to build the trust chain because the server does not trust the issuer CA of the clients certificate directly and thus needs the intermediate certificates.
I am new to Cryptogrphy, HTTPS and SSL !!!
If i am not wrong , the private key of an End Entity certificate (certificate issued by trusted CA like Verisign) is used to decrypt the information sent by the client !
But does a root certificate also have a Private Key?
If Yes, then I wanted to know where exactly the private key of a root certificate is used?
What happens if it is leaked ?
If I am not wrong, the private key of an End Entity certificate (certificate issued by trusted CA like Verisign) is used to decrypt the information sent by the client
You are wrong. It isn't. The peer's own private key is used to sign the certificate so the client can verify that the peer owns the certificate he presents, and the private key of signing certificates is used to, err, sign certificates.
The root certificate's private key is (normally) only used to sign the intermediate certificates. Compromising it allows you to create new intermediate certificates, and by extension, certificates for any domain.
A root certificate is the top-most certificate of the tree, the private key of which is used to "sign" other certificates. All certificates immediately below the root certificate inherit the trustworthiness of the root certificate - a signature by a root certificate is somewhat analogous to "notarizing" an identity in the physical world. If you knew the private key, you could create new (counterfeit) certificates.