How to change the expiration date of a GPG key

This post is a step-by-step tutorial on how to extend the expiration date of your GPG keys or reset it in case the keys have already expired. But, before we go through how to change the date, I’d like to write a few things about why setting an expiration date on your GPG keys is important.

The importance of the GPG/PGP key expiration date

Most people set their GPG keys to never expire. There is no problem with that. Unless they lose the private key or it gets stolen or they just forget its passphrase. In such a case, the public key, which has probably been published to several key servers around the world and retrieved by an arbitrary number of other people, is practically useless and, apart from removing it from some of the keyservers, they can do absolutely nothing else about it, unless, of course, they had previously generated a revocation certificate for the public key and they still have access to this certificate. In those not so rare cases that the revocation certificate is not available, the only way to let those who have already grabbed a copy of the public key know that they should not use that key any more is by notifying them directly, which is not always possible since the actual number of the holders of that specific public key is not known.

Setting an expiration date on your keys is a very good security measure. It lets the holders of the public key know the key’s end-of-life date. On the other hand, you can always extend the key’s expiration date and send the updated key to the key servers. When others find out that your public key has expired, the very first thing they do will be to refresh it from a key server, in which case they’ll retrieve your updated public key. Even if you lose the private key or forget the passphrase or even lose the revocation certificate too, a time will come that the public key will expire, which indicates that it is invalid and should not be trusted any more. This is important.

Change the expiration date of a GPG key

In this section I describe how to extend or reset a key’s expiration date using gpg from the command line. There are probably several graphical front-ends out there that might simplify this procedure, but, since graphical frontends are not usually cross-platform, I choose to use the command-line gpg utility. So, here is how we do it.

First of all, you have to know the ID of the key you need to edit:

$ gpg --list-keys
pub   1024D/B989893B 2007-03-07 [expired: 2009-12-31]
uid                  George Notaras <gnotaras@example.org>
sub   4096g/320D81EE 2007-03-07 [expired: 2009-12-31]

The ID in question is B989893B, so we edit the key with that ID:

$ gpg --edit-key B989893B

You should have entered the gpg shell by now. To see a list of the available commands you can always invoke the help command.

First of all, list the keys so you know what you are editing:

gpg> list

pub  1024D/B989893B  created: 2007-03-07  expired: 2009-12-31  usage: SCA
                     trust: ultimate       validity: ultimate
sub  4096g/320D81EE  created: 2007-03-07  expired: 2009-12-31  usage: E
[ ultimate] (1). George Notaras <gnotaras@example.org>

By default, no subkey (sub) is selected, which means that we work on the primary key (pub). It is possible to select the subkey you will be working on by invoking the key command followed by the number (index) of the subkey you wish to select. If no arguments or index ‘0’ is passed to the key command, any subkey is deselected and you will be working on the primary key.

gpg> key 0

pub  1024D/B989893B  created: 2007-03-07  expired: 2009-12-31  usage: SCA
                     trust: ultimate       validity: ultimate
sub  4096g/320D81EE  created: 2007-03-07  expired: 2009-12-31  usage: E
[ ultimate] (1). George Notaras <gnotaras@example.org>

Now use the expire command to set an expiration time for the primary key.

gpg> expire
Changing expiration time for the primary key.
Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0) 2y
Key expires at 10/28/12 03:51:07
Is this correct? (y/N) y

You need a passphrase to unlock the secret key for
user: "George Notaras <gnotaras@example.org>"
1024-bit DSA key, ID NNNNNNNN, created 2007-03-07


pub  1024D/B989893B  created: 2007-03-07  expires: 2012-10-28  usage: SCA
                     trust: ultimate       validity: ultimate
sub  4096g/320D81EE  created: 2007-03-07  expired: 2009-12-31  usage: E
[ ultimate] (1). George Notaras <gnotaras@example.org>

The output above indicates that the expiration date of the primary public key has been set to 2012-10-28. Note that, the expiration date has also been changed on your primary private key of the keypair. You can issue the toggle command to verify the private key’s expiration date. Don’t worry about that. It is the private subkeys, which never expire, that are actually used when you decrypt and sign data. Read more on this in a special note at the end of this section. For now, just issue the toggle command once again to return to public key editing mode.

In this example case, there is one public subkey on which we need to set a new expiration date. That’s key number 1. We select that with the key command:

gpg> key 1

pub  1024D/B989893B  created: 2007-03-07  expires: 2012-10-28  usage: SCA
                     trust: ultimate       validity: ultimate
sub*  4096g/320D81EE  created: 2007-03-07  expired: 2009-12-31  usage: E
[ ultimate] (1). George Notaras <gnotaras@example.org>

Set a new expiration time on that subkey by invoking the expire command:

gpg> expire
Changing expiration time for a subkey.
Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0) 2y
Key expires at 10/28/12 03:02:43
Is this correct? (y/N) y

You need a passphrase to unlock the secret key for
user: "George Notaras <gnotaras@example.org>"
1024-bit DSA key, ID NNNNNNNN, created 2007-03-07


pub  1024D/B989893B  created: 2007-03-07  expires: 2012-10-28  usage: SCA
                     trust: ultimate       validity: ultimate
sub* 4096g/320D81EE  created: 2007-03-07  expires: 2012-10-28  usage: E
[ ultimate] (1). George Notaras <gnotaras@example.org>

Now it seems that everything is set up fine. You have changed the expiration dates of your keys. You can always use the list command to list the keys. Use the toggle command to toggle between public and private key editing mode.

As a final step you need to save your changes. Invoke the save command.

gpg> save

So, now you can update the public key that is stored on the various keyservers. To achieve this use the following command. In this example, the keyserver at pgp.mit.edu is used.

$ gpg --keyserver pgp.mit.edu --send-keys B989893B
gpg: sending key B989893B to hkp server pgp.mit.edu

Enjoy.

Important Note

If you tried to use the expire command in private key editing mode, you would notice that it is not possible to change the expiration date of any subkeys in this mode. Actually, the private subkeys never expire. Although, I haven’t investigated this, common sense indicates that, since private subkeys are used to sign and decrypt data and that they are not meant to be distributed, it wouldn’t make any sense if they expired.

Theoritically speaking, the owner of an expired private key should still have the ability to decrypt data and also be able to sign data, even if all public subkeys of the current keypair have expired, since it is always possible to reset the expiration date on the currently expired public keys.

As I mentioned earlier, I haven’t investigated this, but I think that non-expiring private keys make a lot of sense.

Final Thoughts

This article described in detail how to change the expiration date of GPG/PGP keys. This should be a standard key maintenance procedure if you set an expiration date on your keys.

Setting an expiration date on your keys is not mandatory as long as you have taken other measures to protect the private key and the public key’s revocation certificate by backing it up and storing it at another location. But, in general, it is a good habit as explained in this article’s introduction. I by no means am a GPG/PGP expert. I wrote this guide because I realized that most people do not set an expiration date on their keys because they do not know how to change it and extend the key’s life or because they have not realized the importance of the expiration date or simply because they do not care. I hope you find this tutorial useful and start setting an expiration date on your keys from now on.

How to change the expiration date of a GPG key by George Notaras is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Copyright © 2010 - Some Rights Reserved

George Notaras avatar

About George Notaras

George Notaras is the editor of the G-Loaded Journal, a technical blog about Free and Open-Source Software. George, among other things, is an enthusiast self-taught GNU/Linux system administrator. He has created this web site to share the IT knowledge and experience he has gained over the years with other people. George primarily uses CentOS and Fedora. He has also developed some open-source software projects in his spare time.

23 responses on “How to change the expiration date of a GPG key

  1. Fabio Varesano Permalink →

    Thanks for writing this article.. this was exactly what I was looking for when I discovered that my key was expired.. thanks!

  2. Ludvig Andersson Permalink →

    I was searching for some recommendation regarding whether I should set expiration dates or not on my GnuPG keys. This article gave me the insight I needed.

    Thanks!

  3. James Permalink →

    Thanks alot for this great blog entry, it was exactly what i needed!

  4. John Martinez Permalink →

    Thanks for this. I didn’t realize you could update the expiration date on a key. That’s sort of cool, and I can see where it’s useful to have old keys that expire unless you periodically refresh them as a casual precaution against *losing* you key, but it seems to me that if your private key is *stolen*, [along with passphrase] then the thief could change the expiration and post a ‘refreshed’ key on the public keyservers, no?

    I bring this up because, in the second paragraph, you mention the key being stolen as one of the things expiration helped protect you from, and I just wanted to point out to your readers that [unless I’m mistaken, which certainly happens sometimes,] it doesn’t really protect you from somebody else who gains access to your private key and passphrase from impersonating you indefinitely. So it’s not a substitute for a revocation cert, even if it is the next best thing…

  5. George Notaras Post authorPermalink →

    @John: Keeping the passphrase and the private key at the same place is like keeping the combination that opens a safe on a sticker on the safe. You wouldn’t do that. It’s the worst practice possible. If both the private key and its passphrase get stolen by the same person, then there is absolutely nothing you can do to recover it.

    Also, the expiration date is not an alternative to a revocation certificate, but could work as an alternative under the conditions I described in the post.

    Thanks for your feedback.

  6. Ryan Permalink →

    Thanks for this post George. I’m just getting back into encryption and realized, after generating a new key, that I hadn’t slapped on an expiration date nor, perhaps even worse, had any idea what was best practice (even though it’s kind of common sense to put an expiration date on something).

    The tutorial is great and clearly outlines the steps needed to update a key. So, thanks again for putting this on the web.

  7. Marina Permalink →

    Thank you. I have an issue where when I try to import a public PGP key (that has NO expiry set), into GPG, it shows the key as expired in gpg causing issues. This is an active key and get the error even after ‘trusting’ it from within gpg. Any thoughts? tried to export the pgp key using –export-format compatible and that didnt help. It more looks like some compatiblity and any direction is appreciated. kindly let me know- thanks

    1. George Notaras Post authorPermalink →

      Hello Marina! Maybe there is some kind of incompatibility between the PGP public key and the GPG version you are using. You could check the gpg man page for the support of any of the following swtiches: --pgp6, --pgp7, or --pgp8. If supported by your GPG version, you could try using any of them while importing the key in you gpg public keyring. Hope this helps!

  8. Guillaume Permalink →

    Thanks a lot for this good explanation. I was looking for that point for a while…

  9. Charlie Norton Permalink →

    Question:
    If I change the expiration date before the key expires, will the old public key still work until it expires and I can still decrypt files with the new edited key? Giving me time to push the new public key out to all my friends.

    Thanks

  10. David T. Permalink →

    Hi!
    Thanks for the excellent manual!
    I have problem with an expired public key – I followed all of your steps, but when I hit “expired” I get the following message: Need the secret key to do this.”
    Any idea why this message comes up and how to fix it?
    Thanks :)

  11. Dale Walsh Permalink →

    I’m experiencing the same issue, I have recently restored a crashed computer and have lost the private key so how can I revoke the key or generate a new private key, I know the passphrase if it matters.

    1. George Notaras Post authorPermalink →

      Hi Dale,

      Revoking the public key will require that you had generated a revocation certificate and that you still have access to it. If the private key is lost, I’m afraid it’s no longer possible to revoke your public key.

      If the revocation certificate is available, revoke your key by simply importing the revocation certificate ( revoke-MYKEYID.asc) into your keyring:

      gpg --import revoke-MYKEYID.asc
      

      Don’t forget to update the key servers, for instance:

      gpg --keyserver pgp.mit.edu --send-keys MYKEYID
      

      Hope this helps.

      PS: BTW, Provided that you have access to the private key, generating the revocation certificate can be done with the following:

      gpg --output revoke-MYKEYID.asc --gen-revoke MYKEYID
      
  12. rahul Permalink →

    Public key I provided from my server to a third party got expired and they complained that they are not able to encrypt the file.
    So I extended the public key as mentioned above.
    Now do I have to export the public key again to send it to them.

    1. George Notaras Post authorPermalink →

      Hi, yes that’s the expected procedure, but I highly recommend uploading the public key to a key server.

  13. Prad Permalink →

    I would like to do these exact steps (updating expiration date) in C# code, without being interactive like it does in the console. Is there any way to do this?

    1. George Notaras Post authorPermalink →

      Changing the expiration date in non interactive mode is something I haven’t tried, but it’s a good idea. Please keep in mind that you will have to pass the passphrase of your private key before the change takes effect and, if this step is one non interactively, might be a security risk.

      1. Prad Permalink →
        echo 1234| gpg2 --passphrase-fd 0 --edit-key keyname@example.com expire
        

        This will take the passphrase without prompting. But I am unable to automate the rest of the commands that follow expire, like specifying the expiry date and finally saving it. Is there a way to do this without interference? Anything you can point me too, absolutely no help on this one.

  14. Harvey Permalink →

    I too get the “Need secret key to do this” when I enter the Expire command, so I cannot change the expiration date. are there any tricks for getting past this problem ?

    1. George Notaras Post authorPermalink →

      Unfortunately, no. The availability of the private key is mandatory before changing the expiration date of a public key.