Error message?
Knute Johnson
field=cn_issuer, status=failed to extract CN: 64 Time(s)
I'm getting more of these all the time. Could somebody explain what it
means?
Thanks,
--
Knute Johnson
s/nospam/knute2011/
Ralf Soergel
> STARTTLS=client, relay=cluster8.us.messagelabs.com.,
> field=cn_issuer, status=failed to extract CN: 64 Time(s)
>
> I'm getting more of these all the time. Could somebody explain what
> it means?
It seems you initiate as client a new SSL/TLS connection to the server
cluster8.us.messagelabs.com and the server uses a incorrect
certificate. Maybe the CN of the certificate or the CN of the
certificate's issuer is empty or a wildcard. This breaks the standard.
Kind regards
Ralf
--
Linux is like a wigwam: no Windows, no Gates, Apache inside
Knute Johnson
> Knute Johnson<nos...@knutejohnson.com> writes:
>
>> STARTTLS=client, relay=cluster8.us.messagelabs.com.,
>> field=cn_issuer, status=failed to extract CN: 64 Time(s)
>>
>> I'm getting more of these all the time. Could somebody explain what
>> it means?
>
> It seems you initiate as client a new SSL/TLS connection to the server
> cluster8.us.messagelabs.com and the server uses a incorrect
> certificate. Maybe the CN of the certificate or the CN of the
> certificate's issuer is empty or a wildcard. This breaks the standard.
>
> Kind regards
> Ralf
>
Thanks Ralf. I thought I had found the problem in that my FQDN did not
match my CN. I reset the FQDN and recreated the sendmail key and
certificates but the problem still exists. The mail does get delivered.
The CN is the commonName correct? I may not have something correct when
I created the certificates, just not sure what.
Claus Aßmann
> STARTTLS=client, relay=cluster8.us.messagelabs.com.,
> field=cn_issuer, status=failed to extract CN: 64 Time(s)
>
> I'm getting more of these all the time. Could somebody explain what it
> means?
See the fine documentation:
${cn_issuer}
The CN (common name) of the CA that signed the
presented certificate (STARTTLS only). Note: if
the CN cannot be extracted properly it will be
replaced by one of these strings based on the
encountered error:
BadCertificateContainsNUL CN contains a NUL character
BadCertificateTooLong CN is too long
BadCertificateUnknown CN could not be extracted
In the last case, some other (unspecific) error
occurred.
If you use
openssl s_client -starttls smtp -debug -connect cluster8.us.messagelabs.com:25 -showcerts
you'll see that the issuer doesn't have a CN.
Ralf Soergel
> On 12/29/2010 10:03 AM, Ralf Soergel wrote:
>> Knute Johnson<nos...@knutejohnson.com> writes:
>>
>>> STARTTLS=client, relay=cluster8.us.messagelabs.com.,
>>> field=cn_issuer, status=failed to extract CN: 64 Time(s)
>>>
>>> I'm getting more of these all the time. Could somebody explain what
>>> it means?
>>
>> It seems you initiate as client a new SSL/TLS connection to the server
>> cluster8.us.messagelabs.com and the server uses a incorrect
>> certificate. Maybe the CN of the certificate or the CN of the
>> certificate's issuer is empty or a wildcard. This breaks the standard.
>>
>
> Thanks Ralf. I thought I had found the problem in that my FQDN did
> not match my CN. I reset the FQDN and recreated the sendmail key and
> certificates but the problem still exists. The mail does get
> delivered.
In this case the error message would say something like
"mismatch". But it says "failed to extract", IMO more early in the
arbitrary chain than on matching check.
The mail goes get delivered, but without SSL/TLS transport
security. The further log should display this fact.
> The CN is the commonName correct? I may not have something correct
> when I created the certificates, just not sure what.
Yes CN is the commonName.
But IMO the client certificate isn't the problem. Your sendmail client
session wants to extract the CN from server's certificate and check it
against servers's FQDN obtained from DNS. The server's FQDN should
match its certificate's CN. But during extraction of CN from server's
certificate occurs an error, just before check its content. The CN
must not be empty and should a maximal length 64 chars. Some SSL
implementations check max length, some do not. OpenSSL does.
I've checked your server cluster8.us.messagelabs.com and found a
server certificate with subject
/emailAddress=sup...@messagelabs.com/C=GB/ST=Gloucestershire/L=Barnwood/O=MessageLabsLimited/OU=Operations/CN=mail200.messagelabs.com
you see, the commonName mismatches the FQDN. This ist a certificate
failure, but it seems not the reason of your error message.
The issuer of this server certificat above is a intermediate CA and has the subject
/C=GB/O=MessageLabs/OU=MessageLabs CA
and the issuer of this intermediate CA is a self signed root CA and
has the subject
/C=GB/O=Trustis Limited/OU=Trustis FPS Root CA
Now you can see, that both the CA certificates have an empty CN. This
violates the standard an is IMHO the reason of your error message.
kind regards
Claus Aßmann
> The mail goes get delivered, but without SSL/TLS transport
^^^^^^^ wrong.
> security. The further log should display this fact.
STARTTLS is NOT affected by this, it is being used. If TLS
would not be used, that log message would not appear.
Knute Johnson
Thanks Claus and Ralf for the information.
--
Knute Johnson
s/nospam/knute2011/
Ralf Soergel
<ca+sendmail(-no-copies-please)@mine.informatik.uni-kiel.de> writes:
Thanks for correction, claus