I am trying to understand how a self-signed certificate created by ROOT CA, can be used to validate (decrypt) a certificate signed by the private key used by ssCA.
I currently dont need an external CA, so i decided to use my own self signed Root CA, to sign other certificates.
Self Signed Certificate by Root CA is created using a private key (root.key). The certificate contains the public key of Root CA and some meta info.
Now if i use the root.key to sign another certificate C, how does the C can be validated by the self signed certificate of Root CA? (Isnt the self-signed certificate of Root CA encrypted by the root.key itself, and it has its public key as part of the signature. How will that signature be decrypted to obtain the exact public key?)
Isn't the self-signed certificate of Root CA encrypted by the root.key itself, and it has its public key as part of the signature
Signing and encrypting are orthogonal, i.e. data can be signed but not encrypted, they can be encrypted but not signed or they can be both signed and encrypted.
A certificate is signed, not encrypted.
Related
I have an existing Server Keystore.
keystore : server_keystore.jks.
alias : abc
CN : DNS1
SAN : DNS1, DNS2, DNS3
Requirement is to replace the self signed cert to CA signed certs.
Now, Another person from my team creates a Keystore for each of the 3 servers.
DNS1.jks
DNS2.jks
DNS3.jks
& creates a cert signing request by generating ".csr" files for each of the DNS.
Now from CA Authority we receive 3 CA signed certificates ".cer" files
I imported all three .cer to server_keystore.jks as trusted ca certs.
root
Intermediate
CA signed DNS1.cer with alias name DNS1
CA signed DNS2.cer with alias name DNS2
CA signed DNS3.cer with alias name DNS3
Q1. Is this valid server Keystore ?
Q2. Can client establish secure connection to my server ?
Q3. How do we replace self signed cert with CA signed cert? Is it with same alias name ?
Got the answer.
1. Its not a valid Server Keystore because self signed key-pair public cert has to be replaced with CA reply public certs.
Then only server can reply with CA signed public certificate & client can validate that CA signed certificate chain to it's known CA roots.
Yes, but you need to share explicitely your server public certs with client & client needs to add your self signed certificate to it's list of trusted certs.
Yes, you need to replace self signed public cert in key pair with CA signed one using same alias name which was used to create the key pair.
Example command:
keytool -importcert -alias -file -keystore .jks -trustcacerts
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 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.
Public and private-key pair will be generated during the creation of CSR on our server. We will send the CSR and public key to CA by holding private key with us. CA will validate our public key before signing it with private key of CA's root certificate. We are having our own CA team to certify the CSR requests. My queries are as follows:
Will CSR itself includes public key or do we need to provide public key separately to CA ?
Will CSR be signed by our public key before sending it to CA (or) CSR hold public key besides it?
Will CA sign over only over CSR (or) on the combined set of CSR + public key.?
Should we install CA's root and intermediate certs in our trust store both on the client and server side? since we are using our own CA instead of Global CA.
When we are presenting server certificate to client, will that cert includes public key of server.?
Should we install the server's public key in the truststore of clients for encryption purpose?
Thanks for the help, in advance.
Will CSR itself includes public key or do we need to provide public key separately to CA ?
The public key is inside the CSR
Will CSR be signed by our public key before sending it to CA (or) CSR hold public key besides it?
The CSR is signed by your key. The public key is not enough but the private is needed for signing.
Will CA sign over only over CSR (or) on the combined set of CSR + public key.?
The CA will extract the information from the CSR including the public key and sign it. It will not sign the CSR itself.
Should we install CA's root and intermediate certs in our trust store both on the client and server side? since we are using our own CA instead of Global CA.
Only the root needs to be stored at the client as trust anchor. The intermediate certs should be send by the server together with the servers certificate inside the SSL handshake.
When we are presenting server certificate to client, will that cert includes public key of server.?
Yes, a certificate is the public key and additional information like subject (hostname).
Should we install the server's public key in the truststore of clients for encryption purpose?
No. The client will get the certificate during the SSL handshake. You only want to know about the servers certificate or public key before doing the handshake if you use certificate pinning.
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.