Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[higgins-dev] STS Certificate Usage

Mike,
 
We would like to use a certificate other than our IdP STS SSL certificate to sign tokens.  At first glance, it appeared that the Higgins STS had provided for this by having two different settings in the configuration file: IssuerCertificate and SSLCertificate.  However, when we tried to make them different we ran into problems.
 
The IssuerCertificate is inserted into the mex policy in place of the "urn:CERTIFICATE" string (see MetadataExchangeService.java).  It is also used to sign tokens (see TokenGeneratorHandler.java).  It appears that SSLCertificate is only used in the ProfileService.  If the certificate inserted into the mex data is not SSL certificate of the IdP STS, CardSpace will complain.  You get an error in the event log stating that the IdP's SSL certificate thumbprint does not match the thumbprint of the certificate in the mex data.  We asked Microsoft about this, and this was their response:
 

"CardSpace checks that the same identity cert in the mex policy is the same cert used to set up a channel with the sts.  This is to build a chain of trust from the policy, to the IP STS."

 

They also point out that the token signing certificate can be different than the identity cert in the mex policy.

 

The problem in the Higgins STS is that if we insert the IssuerCertificate in the mex data, it means that IssuerCertificate has to be the same as the SSL cert for the IdP STS.  Because IssuerCertificate is also used for token signing, it effectively means that:
 
IssuerCertificate == IdP STS SSL Certificate == token signing certificate
 
We are effectively left in a situation where the signing certificate has to be the same as the SSL certificate.  It doesn't seem that this was intentional, but perhaps an oversight.  We would like to be able to get away from that limitation and use use a different certificate than the SSL certificate for token signing.
 
It appears that this problem could be fixed very easily by modifying MetadataExchangeService.java to insert the SSLCertificate into the mex data instead of the IssuerCertificate, and then only use IssuerCertificate for token signing.
 
Does this seem like the right solution to you?
 
Thank you,
 
Daniel Sanders
 

Back to the top