Why does generating a self-signed X509 certificate not require my public key?

Question

Let's say I have an RSA (2048) keypair that I generated

private.key
public.key

For testing purposes I'd like to generate a self-signed X509 certificate.

My understanding of a certificate is that it -

1. Shows proof of ownership of the public key, as verified by some other party (in this case verified by me, since self-signed)
2. Contains the public key within itself

It looks like openssl lets me create a certificate pretty easily:

openssl req -new -key private.key -out certificate.csr

But here's where I'm confused - why does it require my private key?

I can imagine it probably needs to sign it with something, hence the use of the private key. But then, how does it get my public key to embed into the certificate? It's mathetmatically impossible for it to reverse-engineer my public key from my private key, right?

Thanks!

Answer 1

The private key is the secret that identifies you, any signing or verification of your specific identity need the private key. So any operations that will generate something meant to be derived from your identity will require it.

Also, you are not creating a certificate here, you are creating a certificate signing request, something you would hand to another party to whom would then generate the certificate to grant you access.

if you want to create a self signed x509 certificate you should add the -x509 parameter, something like this:

openssl req -x509 -nodes -days 5000 -newkey rsa:2048 -keyout mypem.key -out mycert.crt

• where days are how long the cert is valid (5000 is effectively indefinite)
• nodes skips password business (skip for testing, omit for anything real)
• and also output the key and cert for later use

And @bartonjs is correct, private key to public key is possible, public key to private key is not. That's why you can hand out the public key and noone can use that to impersonate you. The private key must be secret at all times.

If you are planning to act as the client wishing to gain access to the server and also the server granting the request you will first need to set up your certificate authority on the server, and the server's certificates.

Somone on stack overflow has a great answer on this already:

• https://stackoverflow.com/questions/21297139/how-do-you-sign-certificate-signing-request-with-your-certification-authority

But the basic juiste is, you set up the CA and crt of the server then you do something like this on the server:

openssl x509 -req -days 30 -in request.csr -CA ca.crt -CAcreateserial -CAkey ca.key -out signedrequest.crt 

you hand the "signedrequest.crt" back to the person who requested it.

I forgot to mention, get rid of -nodes in my command above, it skips the password process. Good for testing, Bad for security. Just FYI.

Answer 2

It's mathetmatically impossible for it to reverse-engineer my public key from my private key, right?

Nope, your direction is backwards.

From a public key it's (supposed to be) impossible to get a private key. From a private key the public key is easy.

For RSA the private key is (n, d), but more practically it's (p, q, e). p*q = n, and (n, e) is the public key.

For ECDSA the private key is d, the number you multiply G by to get Q, the public key. Since you need to remember the curve you're on anyways, that gives you G, and d*G still is Q, the public key.

Answer 3

The private key file contains all of the keypair components (and even I not the public part can be calculated from the private parameters) It does contain the public part which it puts into the self signed certificate or certificate signing request, and it needs the private part to actually do the (self)signing.

You can export the public part from the private key file with:

openssl rsa -pubout -in private_key.pem -out public_key.pem