The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Stefan Winter <stefan.winter AT restena.lu>]

Oh,

it actually IS forbidden to have the same names and still wanting a cert to be part of a validation chain:

RFC 5280, section 4.1.2.4:

"If the names in the issuer and subject field in a
   certificate match according to the rules specified in Section 7.1,
   then the certificate is self-issued."

In essence, the certificate says it is self-signed, while the CAT profile is told to have the supplicant construct a path to a different CA with the same name.

I'm not surprised that this creates issues in the auth process. And only mildly sad that our code wasn't anticipating this kind of pathological corner case.

Greetings,

Stefan

On 03.12.21 14:39, Stefan Winter wrote:

Hi,

The CA is not conformant to the IETF PKIX CA profile. IOW, "it's not a CA".

A certificate is a root CA certificate if it's Issuer = Subject and the Basic Constraints extension has an entry: CA = TRUE ** and the Basic Constraints extension itself is marked critical **.

RFC 5280 section 4.2.1.9: "

Conforming CAs MUST include this extension in all CA certificates
   that contain public keys used to validate digital signatures on
   certificates and MUST mark the extension as critical in such
   certificates."

For your CA, the "marked critical" part does not hold true.

This would normally be pointed out by the realm reachability checks; but it appears that the additional complication of having an end-entity cert for which Issuer = DN holds true even though it's not intended to be a self-signed CA triggers some bug.

TBH, I haven't yet encountered this constellation. It is probably not forbidden to issue CA and server cert with the same DN. But such a practice definitely has potential for unintended consequences.

I'll wait for Tomasz's investigation to complete on why we go into 500 there.

Stefan

On 02.12.21 08:56, Zenon Mousmoulas wrote:

Hi,

we have noticed the realm check is failing for an IdP (in our constituency) and profile recently added to CAT:

https://cat.eduroam.org/diag/action_realmcheck.php?inst_id=7420&profile_id=8722

The underlying XHRs to https://cat.eduroam.org/diag/radius_tests.php return 500 after a while.

The respective CA/server certs (also attached here) are a bit peculiar, in that they have the same subject, but other than that we did not notice any show-stopper issue.

Can you help us understand the problem from the perspective of CAT?

Thank you in advance,
Zenon Mousmoulas
GRNET
To unsubscribe, send this message: mailto:sympa AT lists.geant.org?subject=unsubscribe%20cat-users
Or use the following link: https://lists.geant.org/sympa/sigrequest/cat-users
      
      To unsubscribe,
        send this message:
        mailto:sympa AT lists.geant.org?subject=unsubscribe%20cat-users
        Or use the following link:
        https://lists.geant.org/sympa/sigrequest/cat-users