Quite a funny and strange behaviour

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Quite a funny and strange behaviour

Walter H.
Hello,

it is already solved, but I just want to tell others;

I have two VMs, one with an older CentOS 4.x and one with a new CentOS 6.5

both run Postfix as MTA; both have configured a smarthost;
the smarthost allows STARTTLS and has a certificate, that is
issued by AlphaSSL; the

Authority Information Access:
  CA Issuers - URI:http://secure2.alphassl.com/cacert/gsalphag2.crt

this certificate (alphassl.txt) and it's root certificate (rootvalid.txt)
are attached;
the older CentOS 4.x has in it's ca-bundle.crt a root certificate that
expired at the end of last month (on Jan. 28th, 2014), also attached
(rootexpired.txt), no other valid root certificate of this CA (GlobalSign)
can be found in this ca-bundle.crt;

since then the /var/log/maillog shows the following

date time centos4x-vm postfix/smtp[0000]: certificate verification failed
for smarthost: num=10:certificate has expired
date time centos4x-vm postfix/smtp[0000]: certificate verification failed
for smarthost:certificate has expired
date time centos4x-vm postfix/smtp[0000]: Server certificate could not be
verified

the certificate of the smarthost itself has not expired:
   Signature Algorithm: sha1WithRSAEncryption
        Issuer: O=AlphaSSL, CN=AlphaSSL CA - G2
        Validity
            Not Before: Nov  7 16:01:13 2012 GMT
            Not After : Nov  8 16:01:13 2015 GMT

the linux clock is correct, syncs via a few NTP servers;

can someone tell me in clear logic, how it can be, that a totally
different root certificate was used to verify the server certificate?

I just copied the ca-bundle.crt from the new CentOS 6.5 VM to the older
CentOS 4.x VM; not any certificate error in /var/log/maillog since then;

Thanks;

Greetings,
Walter

alphassl.txt (5K) Download Attachment
rootexpired.txt (4K) Download Attachment
rootvalid.txt (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Quite a funny and strange behaviour

Viktor Dukhovni
On Thu, Feb 20, 2014 at 11:26:20AM +0100, Walter H. wrote:

> the older CentOS 4.x has in it's ca-bundle.crt a root certificate that
> expired at the end of last month (on Jan. 28th, 2014), also attached
> (rootexpired.txt), no other valid root certificate of this CA (GlobalSign)
> can be found in this ca-bundle.crt;
>
> can someone tell me in clear logic, how it can be, that a totally
> different root certificate was used to verify the server certificate?

When a root CA is re-issued with the same public key, subject name,
subject key identifier, ... updating only the expiration dates,
and serial number the old root looks like the right issuer of any
certificates issued by the new root to any verifiers (such as your
old CentOS box) that have only that certificate in their trust
store.

The good news for Postfix is that Postfix >= 2.9 ignores all trusted
certificates when doing opportunistic TLS, and never logs certificate
verification failure reasons for opportunistic TLS.  Thus users
don't waste time tweaking CA bundles when delivery proceeds whether
the destination is authenticated or not.

Now if you configure a tls policy of "secure" for mail via the
smarthost, you'll need to point Postfix explicitly at a suitable
smtp_tls_CAfile or smtp_tls_CApath that contain an unexpirted root
issuer.  (Some day you may be able to employ DANE when the smarthost
DNS zone supports DNSSEC and publishes DANE TLSA records for SMTP).

--
        Viktor.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Quite a funny and strange behaviour

Walter H.
On 20.02.2014 17:57, Viktor Dukhovni wrote:

> On Thu, Feb 20, 2014 at 11:26:20AM +0100, Walter H. wrote:
>
>> the older CentOS 4.x has in it's ca-bundle.crt a root certificate that
>> expired at the end of last month (on Jan. 28th, 2014), also attached
>> (rootexpired.txt), no other valid root certificate of this CA (GlobalSign)
>> can be found in this ca-bundle.crt;
>>
>> can someone tell me in clear logic, how it can be, that a totally
>> different root certificate was used to verify the server certificate?
> When a root CA is re-issued with the same public key, subject name,
> subject key identifier, ... updating only the expiration dates,
> and serial number the old root looks like the right issuer of any
> certificates issued by the new root to any verifiers (such as your
> old CentOS box) that have only that certificate in their trust
> store.
Thanks,

this sounds logic to me;

but one question:

in the extensions config file you have this:

subjectKeyIdentifier=hash

which parts of the certificate are included in generating this hash value?


Thanks,
Walter


smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Quite a funny and strange behaviour

Viktor Dukhovni
On Thu, Feb 20, 2014 at 09:11:06PM +0100, Walter H. wrote:

> in the extensions config file you have this:
>
> subjectKeyIdentifier=hash
>
> which parts of the certificate are included in generating this hash value?

It is generally the public key bitstring.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Quite a funny and strange behaviour

Michael Ströder
In reply to this post by Walter H.
Walter H. wrote:
> subjectKeyIdentifier=hash
>
> which parts of the certificate are included in generating this hash value?

http://tools.ietf.org/html/rfc5280#section-4.2.1.2

Ciao, Michael.


smime.p7s (3K) Download Attachment