Unable to distribute a GPG public key when never expires, because it has expired

I have previously distributed a public public key successfully ( for signing open source ), but having returned to the open source project after a few months the build has been unable to locate the public key.

When attempting to re-distribute the key I get

gpg --keyserver keys.openpgp.org --send-key XXX
gpg: sending key XXX to hkp://keys.openpgp.org
gpg: keyserver send failed: Certificate expired
gpg: keyserver send failed: Certificate expired

However the certificate is set to never expire.

> gpg --edit-key  XXX
sec  rsa3072/XXX
     created: ...  expires: never       usage: SC  
     trust: ultimate      validity: ultimate
ssb  rsa3072/YYY
     created: ...  expires: never       usage: E   

Why is it claiming the certificate has expired when it is set to never expire, and how can I renew the public key so it can be used again?

Thanks.

It's talking about the certificate of the key server, not the certificate you're trying to upload. (GnuPG itself almost never calls PGP keys "certificates", it usually reserves that name specifically just for the key signature alone (aka certification), not for the whole keyblock.)

Although keys.openpgp.org accepts cleartext HKP requests (which are HTTP on port :11371), it only ever redirects them to HKPS (i.e. HTTPS on the usual port :443).

$ curl -i http://keys.openpgp.org:11371
HTTP/1.1 301 Moved Permanently
Location: https://keys.openpgp.org/

One possibility is that your system's clock is wrong and is so far ahead that it thinks it's already past December. The other possibility is that it's an outdated TLS client that doesn't correctly validate the certificate to begin with.

On the HTTPS service, keys.openpgp.org is using a Let's Encrypt certificate and is including a certificate chain cross-signed by IdenTrust (DST Root CA X3). That's the same "DST Root CA X3" which expired at the end of September.

If your OS only has the IdenTrust "DST Root" CA but not the Let's Encrypt "ISRG Root" CA installed &ndahs; or if it has both but your GnuPG version is linked against a TLS library that doesn't support alternate verification chains – it will then reject the server's TLS certificate as "expired" because its root CA is expired. Old versions of GnuTLS and OpenSSL don't realize that this isn't the only option.

For example, in Debian oldstable (where gpg uses the GnuTLS library) you need to pick up the libgnutls30 (3.5.8-5+deb9u5 => 3.5.8-5+deb9u6) package upgrade as well as kill any running 'dirmngr' processes in order for it to understand multiple TLS validation chains. In Ubuntu 14.04 you need to remove the DST CA outright.

(The reason Let's Encrypt still offers this as the primary chain is because it happens to provide better compatibility with really old Android versions.)