java question on certificates signing process

Question

I am confused on the process to create a valid certificate,signed by a CA, in java.
I know that java has the tool keytool to create public-private keys and certificates.
Also it supports JKS and PKCS#12.
So one can create a keystore with a public-private key pair and a certificate e.g.
keytool -genkey -keyalg RSA -alias aCert -keystore someKeystore.keystore This will create a keystore with a certificate (self-signed).
So far I understand.
I can export the certificate for a csr request to send to a CA e.g. Verisign, without the private key of course.
After this part I am lost.
The CA will sign it and I will have to re-import it to my keystore?This will replace the original certificate already in keystore?
It will still be self-signed though.
Shouldn't the issuer be the CA itself?But then how is this possible?I just send the public key only and not a certificate?
Any help on clearing the process please?
UPDATE:
Is the CA signing the certificate (e.g. Verisign) also the issuer?Or it can sign a certificate that the issuer==subject?
Thanks

Answer 1

You're correct up to the point of CSR creation. You'll use something like this:

$ keytool -certreq -alias myalias -file myalias.csr -keystore keystore

to generate a CSR, which contains:

• your public key (extracted from the self-signed cert)
• the Distinguished Name (i.e. the name of the entity for whom the cert is requested)

and is signed with your private key. The CA then generates a new certificate with:

• subject = your DN (either from the CSR or auto-generated using details you supplied during the application process)
• issuer = the CA's DN
• public key = from the CSR

which you need to import back into your keystore, replacing the original self-signed cert:

$ keytool -import -alias myalias -keystore keystore -file myalias.crt

Often CAs will sign your new certificate using an intermediate certificate which is in turn signed by a trusted root; in this case you should import the intermediate certificate before your own:

$ keytool -import -trustcacerts -alias intermediate -file intermediate.crt -keystore keystore

Edit: this obscure section from keytool's documentation is surprisingly clear (where it talks about a 'chain' of certificates, this just refers to the intermediate certificates that link yours to the root):

keytool can create and manage keystore "key" entries that each contain a private key and an associated certificate "chain". The first certificate in the chain contains the public key corresponding to the private key.

When keys are first generated (see the -genkey subcommand), the chain starts off containing a single element, a self-signed certificate. A self-signed certificate is one for which the issuer (signer) is the same as the subject (the entity whose public key is being authenticated by the certificate). Whenever the -genkey subcommand is called to generate a new public/private key pair, it also wraps the public key into a self-signed certificate.

Later, after a Certificate Signing Request (CSR) has been generated (see the -certreq subcommand) and sent to a Certification Authority (CA), the response from the CA is imported (see -import), and the self-signed certificate is replaced by a chain of certificates. At the bottom of the chain is the certificate (reply) issued by the CA authenticating the subject's public key. The next certificate in the chain is one that authenticates the CA's public key.

Answer 2

After the CA signs the cert it ceases to be self-signed. A self-signed certificate has issuer == subject. When the CA signs it, issuer becomes the CA, which corresponds to the subject in the CA's own certificate, which in turn is signed by another issuer, ... so you have a certificate chain, that terminates in a trusted root that is already in your truststore.