0

Disclaimer + Background

Since self signed certs are not that popular, here's some context:

I have a 3rd party client/server application that we're currently using (inside the LAN!) via unencrypted TCP/IP. (The protocol is proprietary, not HTTP.) This application offers operation via SSL/TLS by installing a self-signed certificate + private key on the server and per-registering the cert via it's fingerprint on the client installation. When the client connects it will check the server's presented cert via the fingerprint and establish the connection. (And, no, this app cannot utilize the trust store of Windows or anything like that.)

Note that this is just for the client to authenticate the server. Once connection is established, the server will request user/password authentication from the client. No client issued cert involved.

Question

Given this setup: Is there any benefit to separating the private key generation from the certificate generation? It seems that when I have a server that presents a self-signed certificate to clients, changing the cert (on the server) is the same amount of work as changing the cert and the private key that matches that cert.

Certainly in my case??! And since I'm a real noob when it comes to PKI, I was also wondering what the use case would be to generate multiple self-signed certificates from the same private key in a classic client/server scenario?

To clarify further what I mean

The process itself, even with a single openssl invocation, is to first generate the private key, then generate the (x509) certificate from it. These two items have to be "installed" in the server for the self signed cert to work.

Now, say I have this self signed cert valid for 1 year. When I need to renew that cert, is there any point in reusing the original private key to create a new cert vs. just using the single command form of openssl ( req -newkey) to generate both anew and switch them in the server.

It would appear to me that for my software case there is none; but also, as far as my understanding goes so far, even with a "default" webserver case and a self signed cert, managing the private key and the self signed cert separately seems(!) pointless.

Obviously, you need to keep the private key secure, but to me it seems easier to just state that in case I need to change the cert, just regenerate the PK as well.

Note: I have successfully created and tested the pair generated as described in How to generate a self-signed SSL certificate using OpenSSL?.

Improve this question
2
  • separating ... in what sense are you using this term? First you generate the keypair and then you generate the certificate. In that sense they are already separated in time.
    – President James K. Polk
    Commented Oct 21, 2021 at 21:33
  • @PresidentJamesK.Polk - thanks for the clarification request. I have tried to explain better what I mean. (And yes, this is obviously from someone who does not work in this context regularly.)
    – Martin
    Commented Oct 22, 2021 at 6:31

1 Answer 1

Reset to default
1

There is no discernable difference.

Generating a new private key may even be marginally safer, as it would mean a compromised key would now not be in use anymore.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .