I have a server and a single client. I have full control of both, the client is not a distributed application used by the public. For various reasons, I'm having the client use HTTPS to communicate with the server.

My cert is self signed.

I have a specific requirement for the client: It only has knowledge of the server certificate or CA. It doesn't know about any other public CAs or certificates. The client is only meant to talk to the server, it will reject anything else.

When the server's certificate expires, I need to renew it. However, I would prefer not to have to update the client. What are my options?

  • I could have the client ignore the server's expiration date, and not have to renew the cert regularly. Not my favorite option.
  • Could generate the server cert to be an expiration date in the year 9999. However, again, I'd like to rotate the cert if possible.
  • If I make a CA and inform the client of the CA, it allows the server cert to be changed whenever. However, CAs expire too and if I need to update the CA, then I have to update the client.
  • I was looking at HPKP but I do not believe my server & client supports this. If this is the most optimal route in my scenario, I could spend time implementing it on both ends.

Any other ideas I may be missing? I know that if you reuse the same private key and csr, the public key doesn't change. However, just having the same public key seems insufficient for completing the handshake unless I'm mistaken.

  • Why do you want to rotate the certificate? – vidarlo Jan 24 at 18:25
  • @vidarlo - well they expire, and if I set it to not expire (year 9999) or ignore the expiration, it will be something people just assume doesn't have to be maintained or isn't compromised somehow. If I have a step, even if its automated, to generate a new cert every few months or years, then people are more likely to pay attention to it I guess. I just don't want to have to deploy the cert to the server and have to also have something push the new cert to the client if possible. – user99999991 Jan 24 at 18:44
  • Then why not use the public PKI infrastructure that comes for free with all major operating systems, and set up automated Let's encrypt certs? Or if the client is indeed a single client, what's the problem with having essentially infinite lifetime for the certificate? – vidarlo Jan 24 at 18:47
  • If I use Let's encrypt, my understanding is that if the client were to somehow accidentally attempt to communicate with a server that's not mine using the same Let's Encrypt CA, it would send information to it and that unknown server would be able to receive and look at its payload. Per this question: security.stackexchange.com/questions/201937/… – user99999991 Jan 24 at 19:01
  • 1
    Let us continue this discussion in chat. – vidarlo Jan 24 at 19:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.