A sáb, 11-02-2023 às 14:37 -0500, Viktor Dukhovni escreveu:
> 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.
>
It is indeed reproducible after generating and configuring a new
keypair
and rebooting the server.
Thank you for your comments, Viktor, they save me from looking in the
wrong place. I have access to a server running a later version of
Debian
and I'll try the whole coinfiguration there.
