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

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

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