Can self-signed SSL certificate be renewed? How?

Question

I'm fairly new to SSL certificates and would like to know if a self-signed certificate which I use for HTTPS can be renewed to extend its expiry date without all clients of the site having to go through the "allow exception" process they have to do when they visit the site for the very first time or, as when issuing new self-signed certificate created from scratch.

I found the following tutorial showing how to renew a self-signed cert using openssl but I wasn't able to use it such that my browser silently accepts it without showing that "Untrusted Site" warning screen:

  # cd /etc/apache2/ssl
  # openssl genrsa -out togaware.com.key 1024
  # chmod 600 togaware.com.key
  # openssl req -new -key togaware.com.key -out togaware.com.csr
    AU
    ACT
    Canberra
    Togaware
    Data Mining
    Kayon Toga
    Kayon.Toga@togaware.com
    (no challenge password)
  # openssl x509 -req -days 365 -in togaware.com.csr \
            -signkey togaware.com.key -out togaware.com.crt
  # mv apache.pem apache.pem.old
  # cp togaware.com.key apache.pem 
  # cat togaware.com.crt >> apache.pem 
  # chmod 600 apache.pem
  # wajig restart apache2

My setup is pretty much as described in this answer and I am using CRT and KEY files (from this tutorial) instead of a PEM file, so maybe I messed something up trying to apply it to my case.

Then again, I found many forum entries suggesting it is entirely impossible to renew a self-signed cert and I have to create an new one from scratch.

Any help would be appreciated... or would this question better be suited to https://serverfault.com/ or https://superuser.com/ ?

Rather than downvoting this question, please give specific advice what to improve about it. — FriendFX, Jul 21 '13 at 08:37

score 28 · Accepted Answer · answered Jul 21 '13 at 13:38

By definition, a self-signed certificate can be trusted only through direct trust, i.e. what Web browsers like Firefox show as the "allow exception" process. One very specific certificate, down to the last bit, is declared as "trusted". Nothing can be changed in a certificate without exiting from this model, and, in particular, the expiry date, which is part of the data contained in the certificate.

You can imagine renewal as a kind of family thing: when a certificate is "renewed", it is actually replaced by a younger sibling. Clients accept the new certificate silently because it shares the same ancestry as the previous certificate. Self-signed certificates are intrinsic orphans: they have no ancestry. Hence, no sibling, and no automatic transmission.

(Apart from this ancestry thing, renewal is the creation of a new certificate. Certificates are immutable. "Renewal" is a way of thinking about the relationship between the old and the new certificates.)

If you want to be able to do silent renewals, then you need a self-signed CA certificate. You emit certificates for your server(s) from that CA, and you ask your clients to trust that CA. Of course this is asking a lot: a CA that you trust is a CA that can fake the whole Internet in your eyes. Basically, this solution is about creating and maintaining your own CA, which is a responsibility and some work.

Next time you produce a self-signed certificate, make it long-lived. Certificates expire mostly in order to make revocation work (certificate expiry prevents CRL from growing indefinitely). For a self-signed certificate, there is no revocation, so you can make the certificate valid for 20 years. Or for 2000 years, for that matter (although the Year 2038 Problem might show up at some point, depending on the client software).

Thanks for the extensive answer! I am wondering though what that means in relation to the [tutorial](http://linux.togaware.com/survivor/Renew_SSL.html) I linked to. Is that for self-signed **CA** certificates only? I guess I just hoped (and thought after reading the tutorial) there was a way to read in the private key from the old one and creating a new, "compatible" one... one that looks like a "child" rather than an "orphan". Nice analogy, by the way! — FriendFX, Jul 22 '13 at 04:54
@FriendFX - What you want is not possible. Tom is correct the renweal generates a new certificate. — Ramhound, Jul 22 '13 at 12:55
@Ramhound - I understand. The only open question is: what is the purpose of that tutorial then? — FriendFX, Jul 23 '13 at 00:16
@FriendFX - It was written by some random guy on the internet just because they have a blog does not meant they understand what they are writing about. The author simply does not explain that the tutorial will result in a new certificate — Ramhound, Jul 23 '13 at 00:53
@FriendFX Yes, that tutorial will only work for self-signed CA certificates. If you use the same key pair and subject, you can create multiple CA certificates that will each satisfy as a valid issuer for issued certificates; these certificates can even be issued by different parent CAs, which is called "cross-chaining". — Calrion, Oct 14 '13 at 02:32

score 4 · Answer 2 · answered Jul 24 '17 at 14:34

Short answer: No.

Trusting a self-signed certificate is like trusting an individual passport instead of the country issuing that passport. If you get a new passport, it will not be automatically trusted by someone who trusted the old one, specifically because it is a different thing with different attributes (passport number, dates etc); there is no basis for someone explicitly trusting the old passport to know the new one can be trusted.

score 1 · Answer 3 · answered May 23 '17 at 17:20

1

If you're using self-signed certificates(i recommend using xca on windows) you simply can set the expiry date to 7999-12-31(That's the maximum time for UTC) and the initial date to 1970-01-01(For compatibility with misconfigured time/date in PCs)

answered May 23 '17 at 17:20

H3LL0

11
1

score 0 · Answer 4 · answered Nov 25 '21 at 05:53

0

I just updated a self-signed cert for use by postfix/dovecot server and Thunderbird client. Tbird did not fuss.

When I created the original cert, I created the key file. It was stored on the server as /etc/ssl/private/CERT_NAME_KEY.pem

When I made the new cert, I used the old key and did .csr generation and .pem generation using the same two command lines (with appropriate name changes) as the OP used from the "tutorial".

answered Nov 25 '21 at 05:53

Alex Robinson

1

In my experience, IMAP clients (but not all of them) are usually very lenient with self-signed certificates, much more so than web browsers. – StarCat Nov 25 '21 at 07:02
I should have mentioned that I spent a *long* time trying to get TBird to accept a signed cert. TBird not only seemed overly officious (a lot like Firefox), but the dialog box that pops when TBird doesn't like a cert is buggy no matter what UI element is clicked. – Alex Robinson Nov 26 '21 at 08:21
I've not worked with self-signed certificates for some years now, so that might have changed in more recent Tbird versions. – StarCat Nov 26 '21 at 08:26

Can self-signed SSL certificate be renewed? How?

4 Answers4