> Let me try to explain what's going on through a
> scenario, as I promise if I use real names it's likely to be even more
> confusing.
I read this yesterday and gave it some thought. I believe I understand
the configuration and problems you're running into.
> Bob Intermediate Cert-2 is going to sign
> Alice's root certificate, and both will continue to exist in the wild.
> Neither is given an option in this arrangement.
At first I thought, "Whoa, you mean Alice's root CA will have _2_
signatures?" I've done quite a bit of work with X.509 certs and I'm
intimately familiar with RFC 2459. I had to re-read the spec to
confirm that I hadn't missed something imporant, namely that a
certificate can have one and only one signature. The ASN.1 notation
from that RFC:
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
Thus you have changed the certificate chain at this point. The full
PKIX path to certificates in Alice's chain:
A-leaf <- A-intermediate <- A-root <- B-intermediate-2 <-
B-intermediate-1 <- B-root
> machines in Alice's domain begin to become confused about what 'right' looks
> like.
There's only one answer to that question, the chain above. I realize
that certificate chain verification can be a real pain in practice
(recent OSX SSL libs come to mind), but despite implementation woes
there is only one answer.
> Fred presents Fred->Alice Intermediate->Alice Root CA->Bob Intermediate
> 2->Bob Intermediate 1->Bob Root CA, but CAS errors out when it begins to
> evaluate a certificate which isn't actually in the Tomcat truststore
The problem lies with the last clause: "which isn't actually in the
Tomcat truststore." The truststore MUST contain the entire certificate
chain to complete the PKIX path check. In order for a certificate
check to pass, the chain MUST end with a self-signed certificate. I
have read the spec for the PKIX path checking algorithm, but I can't
swear that's a requirement of the spec; I can say it's a requirement
for the JSSE implementation used by both Tomcat and CAS. I'm certain
that you can solve the particular problem above simply by including
the missing certs from Bob's PKI in the Tomcat truststore.
> To my [perhaps incredibly naive] read of the code, Alice now faces three
> options:
Option 1 must be implemented as a JSSE component, e.g. TrustManager,
that you'd need to wire into Tomcat configuration. A popular example
in the Web SSO space is the Shibboleth DelegateToAplication component
[1]. So these sorts of things are possible. But they're not simple. In
fact certificate verification is quite difficult; it's non-trivial for
the common case and down right hard for the edge cases.
I'm not sure you can reasonably implement option 2. You'd have to dig
into so many low-level libraries, including possibly client code
outside your control, that it simply seems non-feasible.
Not sure what you mean by "properly configuring clients." They send a
certificate presented to them. As you noted, it's not necessary to
send an entire certificate chain. Not sure what knobs you could turn
that would have any effect on PKIX path checking on the server other
than to simply use certs from a different issuer.
In any case I'm fairly certain you can solve most if not all of your
problems by tweaking Tomcat connector config on your CAS server. In
fact, Virginia Tech had a similar if not same case a couple years ago:
our root got signed by a well-known trusted CA intermediate. We simply
updated the certs in our container truststore and were able to support
certificates from both the self-signed root CA and the new
GlobalSign-signed root CA. No custom code or unusual configuration
required.
M
[1] https://wiki.shibboleth.net/confluence/display/SHIB2/IdPApacheTomcatPrepare
--
You are currently subscribed to cas-dev@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev
