9

I exported the secret part of my master key for security reasons. Now I had to extend the expiration date of my key for six months.

When typing gpg --list-keys in my console, the following appears

pub   4096R/D11FEC22 2015-04-11 [expires: 2016-04-05]
uid                  Prename Lastname <prename@lastname.com>
sub   4096R/63FD324E 2015-04-11 [expires: 2016-04-05]
sub   4096R/D0A7E7F3 2015-04-11 [expires: 2016-04-05]

Everything seems to be fine.

When typing gpg -K, I get the following:

sec#  4096R/D11FEC22 2015-04-11 [expires: 2015-10-08]
uid                   Prename Lastname <prename@lastname.com>
ssb   4096R/63FD324E 2015-04-11
ssb   4096R/D0A7E7F3 2015-04-11

Why is there still the old expiration date? I can sign any messages. Apparently this date has no influence, doesn't it?

Jens Erat
  • 24,566
  • 12
  • 82
  • 103
null
  • 535
  • 2
  • 14
  • GPG private keys don't expire. It's the public keys that can expire. When you change the expiry date of a public key, what you're effectively doing is sign a new public key with a new expiry date. Ultimately, what matters for GPG isn't the expiry date on your keyring, but the expiry date of your public key on your peer's keyring. – Lie Ryan Jan 01 '17 at 13:24

1 Answers1

1

This must not actually be the problem you encounter, but is a not too unlikely scenario: is it possible you changed the expiration date using GnuPG 2.1? Starting with GnuPG 2.1, private keys are also stored in the public keyring, so GnuPG 1 and 2.0 would read the unmodified private key with the old expiry date from the old private keyring.

Jens Erat
  • 24,566
  • 12
  • 82
  • 103
  • I use gpg (GnuPG) 1.4.16. Does this mean that this expiration can be ignored? – null Oct 10 '15 at 11:20
  • If the expiry date is correctly set in your public key and distributed among the key servers (given your key is distributed there), I'd say you can safely ignore it in the private key. My answer is a possible explanation how this could have happened. – Jens Erat Oct 10 '15 at 11:37