On Sat, Feb 11, 2023 at 06:46:14PM +0000, Nicholas Jacobs wrote:
> > > opendkim[3223]: F29AA21C4C: SSL error:0D07207B:asn1 encoding
> > > routines:ASN1_get_object:header too long
> > > opendkim[3223]: F29AA21C4C: dkim_eom(): resource unavailable:
> > > d2i_PrivateKey_bio() failed
> >
> > The ASN.1 encoding (after base64 decoding the PEM input) of the
> > private
> > key is malformed.
> >
> > On Sat, Feb 11, 2023 at 05:48:45PM +0000, Nicholas Jacobs wrote:
> >
> > > # ls -la /etc/dkimkeys/ gives:
> > > -rw------- 1 opendkim opendkim 1704 Jan 28 18:08 202208250.private
> > > -rw------- 1 opendkim opendkim 1679 Dez 30 18:23 202212301.private
> > > -rw------- 1 opendkim opendkim 1679 Feb 8 10:51 202302081.private
> >
> > There are three private keys there. Report the output of:
> >
> > $ cd /etc/dkimkeys/
> > $ for pk in 202208250 202212301 202302081; do
> > printf "%s: " "$pk"
> > openssl pkey -in "${pk}.private" -pubout -outform DER | wc -
> > c
> > done
> >
> > Which should report the DER byte count of the corresponding public
> > keys. If the key is malformed, an error will be reported.
>
> The output is:
> 202208250: 294
> 202212301: 294
> 202302081: 294
So it seems that the PEM files are acceptable to the OpenSSL CLI, and
the underlying ASN.1 encoding is correct (and it may be noted that the
ASN.1 encoding is not sensitive to LF vs. CRLF newline endings in the
PEM format).
Which then suggests that the issue is at a different layer, somehow the
private key data seen or held by opendkim is not the same as in those
files.
This is not a Postfix issue. If this problem is reproducible even after
generating and configuring a new keypair and restarting opendkim, then
you'll need to decide whether to do the requisite debugging or to look
for a different OS distribution, where the components in question
(Python, opendkim, OpenSSL, ...) don't exhibit the problem you're
seeing.
--
Viktor.
