what am i doing wrong?

[ArkanoiD]

Trying to test pathfinder - test case is certificate for https://money.yandex.ru
, signed by intemediate authority (AIA URI:
http://crls.yandex.ru/YandexExternalCA/YandexExternalCA.der).

No luck:
[ark@grave ~]$ pathclient -t pem Yandex.Money
Certificate is NOT ok. Error: No urls to download object needed to
perform validation.

Sep 9 03:34:23 grave (ugid=103:106 pid=28815) pathfinderd: Received a
request to validate certificate with subject /C=RU/L=Moscow/O=OOO
Yandex/OU=money.yandex.ru/CN=Yandex.Money.
Sep 9 03:34:23 grave (ugid=103:106 pid=28815) pathfinderd: Checked
certificate. Seems to be ok.
Sep 9 03:34:23 grave (ugid=103:106 pid=28815) pathfinderd: Is this
certificate signed with MD5 or MD2? No
Sep 9 03:34:23 grave (ugid=103:106 pid=28815) pathfinderd:
Certificate (/C=RU/L=Moscow/O=OOO Yandex/OU=money.yandex.ru/
CN=Yandex.Money) we just got has an issuer (/DC=ru/DC=yandex/DC=ld/
CN=YandexExternalCA). We continue building the path.
Sep 9 03:34:23 grave (ugid=103:106 pid=28815) pathfinderd: Attempting
to get signer.
Sep 9 03:34:23 grave (ugid=103:106 pid=28815) pathfinderd: Got
certificate with mimetype text/plain.
Sep 9 03:34:23 grave (ugid=103:106 pid=28815) pathfinderd: Checked
certificate. Seems to be ok.
Sep 9 03:34:23 grave (ugid=103:106 pid=28815) pathfinderd: Is this
certificate signed with MD5 or MD2? No
Sep 9 03:34:23 grave (ugid=103:106 pid=28815) pathfinderd:
Certificate (/DC=ru/DC=yandex/DC=ld/CN=YandexExternalCA) we just got
has an issuer (/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions,
Inc./CN=GTE CyberTrust Global Root). We continue building the path.
Sep 9 03:34:23 grave (ugid=103:106 pid=28815) pathfinderd: Attempting
to get signer.
Sep 9 03:34:23 grave (ugid=103:106 pid=28815) pathfinderd:
Encountered error (No urls to download object needed to perform
validation) during path discovery. Aborting.
Sep 9 03:34:23 grave (ugid=103:106 pid=28815) pathfinderd: Path
validated for certificate /C=RU/L=Moscow/O=OOO Yandex/
OU=money.yandex.ru/CN=Yandex.Money. Result: NOT valid

I tried adding:
[Intermediate CAs]
db:41:27:30:4f:1a:f5:5b:3e:84:56:c8:ec:85:98:b3:51:2c:2d:27 = 1

does not seem to change anything. certificate extensions seem to be
valid.. what's wrong?

[ArkanoiD]

..GTECyberTrustGlobalRoot is there and is readable.

[ArkanoiD]

[CA Location]
CN = GTE CyberTrust Global Root, OU = GTE CyberTrust Solutions, Inc.,
O = GTE Corporation, C = US = file:///etc/pki/tls/certs/GTECyberTrustGlobalRoot

does not help either.

[Dave Coombs]

Hi there,

First of all, note that I did make a few path-discovery fixes in the
last two weeks. Are you running the latest software out of the
subversion repository?

In either case, maybe you should send me (dco...@carillon.ca) your
certificate and the chain you're trying to validate, as well as your
pathfinderd.ini file and anything else that might be pertinent. I'll
be happy to take a look and try to find what's going wrong.

You'll also get more debugging info if you run pathfinderd with -
vvvvv. Feel free to send me that output as well.

Regards,
-Dave

[Dave Coombs]

Hi there,

Thanks for sending me the certificates and config information.

1. Your YandexExternalCA certificate doesn't have the
AuthorityInfoAccess extension, so there is no pointer in the
certificate to download the issuing CA's certificate. This is why
specifying a [CA Location] is necessary in this case.

2. There seems to be a bug in the way [CA Location] is handled in
pathfinder currently, and an error in the documentation. The bug is
that = signs in the CA name need to be escaped as %3D. This is a
trivial fix, and I'll go check it into SVN now. The error in the
documentation is that the CA name needs to be specified in / notation
(with the slashes escaped) instead of , comma-notation. Thus, after
you update and recompile, specify the CA Location as %2FC%3DUS%2FO
%3DGTE Corporation%2FOU%3DGTE CyberTrust Solutions, Inc.%2FCN%3DGTE
CyberTrust Global Root = /path/to/file

3. Even after we fix all that, it seems the GTECyberTrustGlobalRoot
self-signed certificate uses an MD5 signature, which pathfinder
disallows by default. This can be enabled by setting [Defaults]Allow
MD5 = 1 in the config file.

I hope this helps... Let me know how it goes.

-Dave


On Sep-8-09, at 7:45 PM, ArkanoiD wrote:

>

[Alex Smirnoff]

Thanks! Comments inline.

On Wed, Sep 9, 2009 at 11:57 PM, Dave Coombs<dco...@gmail.com> wrote:

> 1. Your YandexExternalCA certificate doesn't have the
> AuthorityInfoAccess extension, so there is no pointer in the
> certificate to download the issuing CA's certificate.  This is why
> specifying a [CA Location] is necessary in this case.

Is it, taking into account that GTECyberTrustGlobalRoot is in [Trusted
directories] already?

> 2. There seems to be a bug in the way [CA Location] is handled in
> pathfinder currently, and an error in the documentation.  The bug is
> that = signs in the CA name need to be escaped as %3D.  This is a
> trivial fix, and I'll go check it into SVN now.  The error in the
> documentation is that the CA name needs to be specified in / notation
> (with the slashes escaped) instead of , comma-notation.  Thus, after
> you update and recompile, specify the CA Location as %2FC%3DUS%2FO
> %3DGTE Corporation%2FOU%3DGTE CyberTrust Solutions, Inc.%2FCN%3DGTE
>  CyberTrust Global Root = /path/to/file

Sep 10 00:17:14 grave (ugid=103:106 pid=3868) pathfinderd: Attempting
to get signer.
Sep 10 00:17:14 grave (ugid=103:106 pid=3868) pathfinderd: Open
'file:///etc/pki/tls/certs/GTECyberTrustGlobalRoot':
error:0D07803A:lib(13):func(120):reason(58)

but is is there and is readable :-(

> 3. Even after we fix all that, it seems the GTECyberTrustGlobalRoot
> self-signed certificate uses an MD5 signature, which pathfinder
> disallows by default.  This can be enabled by setting [Defaults]Allow
> MD5 = 1 in the config file.

Isn't it reasonable to allow md5 for self-signed certificates without
allowing it globally as it implies no additional security risk?

[Alex Smirnoff]

..according to my first log, it does not seem that
GTECyberTrustGlobalRoot CA wasn't read. It looks more like it was, but
was not recognized as trust anchor :-(

[Dave Coombs]

Hi again:

>> 1. Your YandexExternalCA certificate doesn't have the
>> AuthorityInfoAccess extension, so there is no pointer in the
>> certificate to download the issuing CA's certificate. This is why
>> specifying a [CA Location] is necessary in this case.
>
> Is it, taking into account that GTECyberTrustGlobalRoot is in [Trusted
> directories] already?

That would be sufficient if the Authority Key Identifier in the
YandexExternalCA certificate matched the Subject Key Identifier in the
GTECyberTrustGlobalRoot.

However, the AKI in YandexExternalCA uses the dirName;serial method of
identifying the issuer, and GTE's root doesn't have SKI at all, though
its subject DN and serial do match what was in Yandex's AKI...
However, I have to admit, this is simply a method of matching that
pathfinder doesn't currently support. Which is unfortunate. :-/

However, pathfinder grew out of our own requirements, and certificates
we routinely encounter support AIA-chasing and/or AKI/SKI matching.

> Sep 10 00:17:14 grave (ugid=103:106 pid=3868) pathfinderd: Attempting
> to get signer.
> Sep 10 00:17:14 grave (ugid=103:106 pid=3868) pathfinderd: Open
> 'file:///etc/pki/tls/certs/GTECyberTrustGlobalRoot':
> error:0D07803A:lib(13):func(120):reason(58)

Try without the "file://" prefix, just using /etc/pki/tls/......

>> 3. Even after we fix all that, it seems the GTECyberTrustGlobalRoot
>> self-signed certificate uses an MD5 signature, which pathfinder
>> disallows by default. This can be enabled by setting [Defaults]Allow
>> MD5 = 1 in the config file.
>
> Isn't it reasonable to allow md5 for self-signed certificates without
> allowing it globally as it implies no additional security risk?

Actually yes, I agree with you. I'll make that change when I have
some time. Thanks for the suggestion!

Regards,
-Dave

[ArkanoiD]

On Sep 10, 12:35 am, Dave Coombs <dcoo...@gmail.com> wrote:

> However, the AKI in YandexExternalCA uses the dirName;serial method of  
> identifying the issuer, and GTE's root doesn't have SKI at all, though  
> its subject DN and serial do match what was in Yandex's AKI...  
> However, I have to admit, this is simply a method of matching that  
> pathfinder doesn't currently support.  Which is unfortunate. :-/

Will there be any fix for that in the nearest future?

> However, pathfinder grew out of our own requirements, and certificates  
> we routinely encounter support AIA-chasing and/or AKI/SKI matching.

It is quite ok for intranet use, but looks like it does not work in
big bad internet my application lives in :-(

Thank you!

[ArkanoiD]

..what is the correct syntax for enabling MD5? I tried both [Defaults]
Allow MD5 = 1 (as you suggested) and [General] Enable MD5 = yes (as
pdf states) but neither seem to work :-(

[Dave Coombs]

>> However, the AKI in YandexExternalCA uses the dirName;serial method
>> of
>> identifying the issuer, and GTE's root doesn't have SKI at all,
>> though
>> its subject DN and serial do match what was in Yandex's AKI...
>> However, I have to admit, this is simply a method of matching that
>> pathfinder doesn't currently support. Which is unfortunate. :-/
>
> Will there be any fix for that in the nearest future?

I can try. I believe it should be possible, but I want to give it
some thought and make sure it gets done right. :) Meanwhile you do
have a workaround.

>> However, pathfinder grew out of our own requirements, and
>> certificates
>> we routinely encounter support AIA-chasing and/or AKI/SKI matching.
>
> It is quite ok for intranet use, but looks like it does not work in
> big bad internet my application lives in :-(

It does handle some quite complicated bridged trust environments (even
on the big bad internet), so long as the certificates meet a certain
profile. If they don't..... well, we're improving it all the time,
thanks to people like you. :)

Thanks,
-Dave

[Dave Coombs]

Whoops. Just checked a fix into SVN.

Thanks,
-Dave

[ArkanoiD]

A quick grep through the dump of root certificate bundle shipped wtih
RedHat Linux revealed:

There are 99 root certificates,
61 of those *do* have ski (38 do not)
41 do have aki (58 do not)
4 are signed with md2 (sic!)
24 are signed with md5

[ArkanoiD]

Just browsed though the code to see if it is easy to get pathfinder to
look up for issuer via subject.
If i get it correctly, we need to (besides bypassing checks that get
the path validation to fail if we have no aki) browse the whole store
instead of list extracted by trusted_store->get, am i right?

[ArkanoiD]

(in get_signer function)

[Dave Coombs]

Something like that. I think I might prefer to change the way
WvX509Store::get() works, to search the stores by criteria other than
just key identifier. It probably won't be too difficult.

The nice thing is I have a test case, in the form of your
certificates. :)

Thanks,
-Dave