The openssl pkcs12 command you used should also export the private key
openssl pkcs12 -in server.pkcs -out server.pem
I guess that the p12 input file does not contain the private key.
Are you sure there is not some kind of warning when exporting the key from the p12 file.
One thing which is important is that it seems that JKS supports a separate key password and a store password. When exporting the p12 from the JKS it can happen that the password for the p12 is different then the password for the key. It seems that this is not supported by openssl (just tried) and results in a "bad decrypt" error. You should make sure that the key password is the same as the p12 password.
In this section we will generate a master CA certificate/key, a server certificate/key certificate and key which is used to sign each of the server and client certificates.
That... I'm guessing that's just the result of copy&paste accidentally mashing two different paragraphs together. It should be like this:
"In this section we will generate a master CA certificate/key which is used to sign each of the server and client certificates."
Why does the certificate Authority have keys in the first place? I thought the job of the Certificate Authority was to sign keys on servers and clients.
Well, yes, and that's exactly what the keys are for – all common types of digital signatures require a keypair. TLS clients & servers use their keys to sign the connection "handshake" data, while CAs use their keys to sign the issued certificates.
Is this private key with people referring to when they talk about master keys or root certificates. And are these root certificates the same thing as private keys?
Close, but no. Certificates only hold the public half of the keypair, along with some extra information (owner name, issuer name and signature, &c.). So they are never the same thing as private keys, but they do always come in matching pairs.
If someone signs a file with their private key, you can verify the signature against the public key stored in their certificate. For example, all issued certs are signed by the CA's private key, and verified against the CA's certificate.
(The CA's own certificate is signed by itself, but there's no point in actually verifying it, since it was explicitly configured as a trusted root.)
So in the end, all the terms you listed refer to the same thing – your new CA has one keypair (a private key and a matching certificate), and uses it to sign all issued certs.
Best Answer
I am just "WOW" - I would not call this secure at any way - according to http://seclists.org/fulldisclosure/2006/Apr/164 private keys are not deleted and stay in system WITHOUT any information about this, I used tried to used app in attached link, but it does not work, however I was able to identify private keys with hexa editor in path
C:\Users\[USERNAME]\AppData\Roaming\Microsoft\Crypto\RSA\[UID]and delete them permanently from system. I am still kind of shocked this is not a bug but feature.