I'm told there isn't specifically a list about the JANET SSL certificate
service and issues, so I'm starting here and excuse any inappropriacy!
We have to replace the certificates which protect the RADIUS/EAP
conversations with our eduroam servers; we'll be using the new JANET
certificate service and, indeed, I have the certificate ready. (Just the
complication with the supplicant reconfiguration to describe.)
However, we've hit a weird issue whereby the certification chains for the
JANET certificates vary between platforms and what's issued by the CA.
Given the chain certificates supplied as part of the application, I have a
AddTrust External CA Root
TERENA SSL CA
However, Windows doesn't have AddTrust External CA Root in it by default,
but will go and fetch it using the 'Microsoft Update Root Certificates
Component' upon first use (see
http://technet.microsoft.com/en-us/library/bb457160.aspx for more info).
It does, however, have the UTN-USERFirst-Hardware CA in as a trusted root.
The result of this is that, if someone hasn't had reason to visit a site
requiring this CA then they won't have it in the list of CAs available in
the dialog box. (However, just browsing a site protected by it will load
it and present it in the list.)
So, I'm wondering what to do -- should we tell people to trust the
UTN-USERFirst-Hardware CA for their eduroam connection and remove the
chain going from that up to AddTrust (*), or might this change in future?
What do the JANET SSL/CA people recommend?
If this may change in future and we must trust the AddTrust External CA
Root one, we have to get people to visit a SSL-protected website (for
example) to get it to appear in the list.
Has anyone tried this yet with 802.1X/EAP?
(*) Firefox has both UTN-USERFirst-Hardware *and* the AddTrust CAs listed
as trusted roots, but only cares about trust on the one at the top of the
chain supplied by the server -- if that goes up to AddTrust, it makes no
difference if UTN-USERFirst-Hardware is trusted or not. I have no idea if
this applies to Windows and its 802.1X supplicant but, if it does, then we
need to manually edit the CA chain to remove the chain up to AddTrust.
Bob Franklin <[log in to unmask]> +44 1223 748479
Network Division, University of Cambridge Computing Service