How do I change the certificate on an IDP web server?

Discussion:

CHLOE SOWERS (BLOOMBERG/ 731 LEXIN)

2012-07-24 20:43:52 UTC

How do I change the certificate on an IDP web server?

I tried to change the certificate on the web server that hosts the IDP, but it gave an error in the SP. Both IDP and SP are behind Apache. The web server certificate is signed for a production server, but I am testing it on a development server. The browser gives the expected warning that the name does not match, which is OK. After credentials are entered, it is passed back to the SP and "Internal Server Error. Please contact the site administrator." is displayed in the browser.

* Shibboleth SP 2.4.2
* The IDP web certificate is changed and Apache recycled.
* SP is recycled too.
* The IDP metadata is freshly loaded into the SP. Viewing the backing file on SP shows same cert IDP is using in relying-party.xml:
<security:Credential id="IdPCredential" xsi:type="security:X509Filesystem">
<security:PrivateKey>/path/to/sso.key</securit$
<security:Certificate>/path/to/sso.crt</securi$
* SP shibboleth2.xml:
<MetadataProvider type="XML" uri="https://sso.dev.company.com/idp/profile/Metadata/SAML"
reloadInterval="7200" backingFilePath="fedmetadata.xml">
* Tried the following in the SP shibboleth2.xml:


* Tried the these settings in the SP Apache (and recycled)
SSLVerifyClient optional_no_ca
SSLVerifyDepth 10
* Tried setting errorFatal=false for all items in security-policy.xml:
<PolicyRule type="ClientCertAuth" errorFatal="false"/>
<PolicyRule type="XMLSigning" errorFatal="false"/>
<PolicyRule type="SimpleSigning" errorFatal="false"/>
<PolicyRule type="XMLSigning" errorFatal="false"/>

No errors in IDP log.

SP log:

<-1>[shibd] DEBUG [[1]] XMLTooling.TrustEngine.PKIX - unable to match DN, trying TLS subjectAltName match
<-1>[shibd] DEBUG [[1]] XMLTooling.TrustEngine.PKIX - unable to match subjectAltName, trying TLS CN match
<-5>[shibd] ERROR [[1]] XMLTooling.TrustEngine.PKIX - certificate name was not acceptable
<-5>[shibd] ERROR [[1]] XMLTooling.SOAPTransport.CURL - supplied TrustEngine failed to validate SSL/TLS server certificate
<-1>[shibd] DEBUG [[1]] XMLTooling.libcurl - SSLv3, TLS alert, Server hello (2):
<-1>[shibd] DEBUG [[1]] XMLTooling.libcurl - SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
<-1>[shibd] DEBUG [[1]] XMLTooling.libcurl - Closing connection #0
<-5>[shibd] ERROR [[1]] Shibboleth.ArtifactResolver - exception resolving SAML 2.0 artifact: CURLSOAPTransport failed while contacting SOAP endpoint (https://sso.dev.company.com/idp/profile/SAML2/SOAP/ArtifactResolution): SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

Nate Klingenstein

2012-07-24 21:14:23 UTC

Permalink

Chloe,

The backchannel for queries between the IdP and the SP is mutually authenticated. The actual tunnel runs between the SP and the web server protecting the IdP's SOAP port, typically 8443.

We've solved the web server's mistrust of your SP, but your SP will need to trust the certificate the web server is presenting. This certificate needs to either be present in your IdP's metadata, or the SP must be able to perform successful PKIX validation of the certificate. In this event, neither was possible, so the connection didn't succeed.

Best to ensure the new SOAP port certificate is in the IdP's metadata and otherwise used by the IdP as configured in relying-party.xml.

Let us know if you have more questions,
Nate.

Semt frim mt iPone

Post by CHLOE SOWERS (BLOOMBERG/ 731 LEXIN)
How do I change the certificate on an IDP web server?
I tried to change the certificate on the web server that hosts the IDP, but it gave an error in the SP. Both IDP and SP are behind Apache. The web server certificate is signed for a production server, but I am testing it on a development server. The browser gives the expected warning that the name does not match, which is OK. After credentials are entered, it is passed back to the SP and "Internal Server Error. Please contact the site administrator." is displayed in the browser.
* Shibboleth SP 2.4.2
* The IDP web certificate is changed and Apache recycled.
* SP is recycled too.
<security:Credential id="IdPCredential" xsi:type="security:X509Filesystem">
<security:PrivateKey>/path/to/sso.key</securit$
<security:Certificate>/path/to/sso.crt</securi$
<MetadataProvider type="XML" uri="https://sso.dev.company.com/idp/profile/Metadata/SAML"
reloadInterval="7200" backingFilePath="fedmetadata.xml">


* Tried the these settings in the SP Apache (and recycled)
SSLVerifyClient optional_no_ca
SSLVerifyDepth 10
<PolicyRule type="ClientCertAuth" errorFatal="false"/>
<PolicyRule type="XMLSigning" errorFatal="false"/>
<PolicyRule type="SimpleSigning" errorFatal="false"/>
<PolicyRule type="XMLSigning" errorFatal="false"/>
No errors in IDP log.
<-1>[shibd] DEBUG [[1]] XMLTooling.TrustEngine.PKIX - unable to match DN, trying TLS subjectAltName match
<-1>[shibd] DEBUG [[1]] XMLTooling.TrustEngine.PKIX - unable to match subjectAltName, trying TLS CN match
<-5>[shibd] ERROR [[1]] XMLTooling.TrustEngine.PKIX - certificate name was not acceptable
<-5>[shibd] ERROR [[1]] XMLTooling.SOAPTransport.CURL - supplied TrustEngine failed to validate SSL/TLS server certificate
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
<-1>[shibd] DEBUG [[1]] XMLTooling.libcurl - Closing connection #0
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
--

--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

CHLOE SOWERS (BLOOMBERG/ 731 LEXIN)

2012-07-25 14:03:57 UTC

Permalink

Ok, I didn't realize there was another port 8443. However, I tried to telnet to that port on the IDP
and it didn't connect. Where is the setting for that port? I tried to grep all of shib-idp/conf/*
and could not find any files that reference 8443. I don't think that port (or any other) is
protected by the web server, because Apache only listens to the SSL port 443 (and 80).

I thought that since the IDP didn't care about the SP's web server certificate, and it doesn't
perform any verification other than with metadata, then the SP wouldn't care about the IDP's
web server certificate either, and would only use metadata. Why make it so that the IDP
only verifies via metadata, but the SP verifies by metadata AND a web server certificate?

How would I add the web server certificate to the IDP metadata? The SP fetches the IDP's
metadata via HTTP and saves it into a file. I see multiple
<security:Credential id="IdPCredential" xsi:type="security:X509Filesystem">
with different ids in relying-party.xml. Would I add the web server cert/key there?
What would I use for id? The id seems to be matched to the
<rp:DefaultRelyingParty provider="urn:company:sso:idp"
defaultSigningCredentialRef="IdPCredential">
Not only that, but I also see this, which is confusing. It's not clear if adding the
web server certificate to this file will publish it to the SP.

<metadata:MetadataProvider id="IdPMD" xsi:type="metadata:ResourceBackedMetadata$
<metadata:MetadataResource xsi:type="resource:FilesystemResource" file="/bb$
</metadata:MetadataProvider>

D:\tmp>telnet sso.dev.company.com 8443
Connecting To sso.dev.company.com...Could not open connection to the host, on
port 8443: Connect failed
--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

Paul Hethmon

2012-07-25 14:30:30 UTC

Permalink

Shib doesn't control what ports your web container listens on. Shib is
simply a web application that depends on the container to pass it requests
that it should handle.

8443 is typically set up for attribute request so that an SP can directly
request from the IdP attributes about a user. Most people set up to push
attributes with the SAML Response instead of attribute request.

So if you've configured your IdP to support attribute requests, then
you'll have to make sure what you publish in the IdP metadata as the URL
for those requests hits your web container and gets to Shib.

Paul

On 7/25/12 10:03 AM, "CHLOE SOWERS (BLOOMBERG/ 731 LEXIN)"

Post by CHLOE SOWERS (BLOOMBERG/ 731 LEXIN)
Ok, I didn't realize there was another port 8443. However, I tried to
telnet to that port on the IDP
and it didn't connect. Where is the setting for that port? I tried to
grep all of shib-idp/conf/*
and could not find any files that reference 8443. I don't think that port (or any other) is
protected by the web server, because Apache only listens to the SSL port 443 (and 80).

--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

Nate Klingenstein

2012-07-25 16:29:32 UTC

Permalink

Chloe,

To add to Paul's answer with a little more detail on some of your
questions...

Post by CHLOE SOWERS (BLOOMBERG/ 731 LEXIN)
I thought that since the IDP didn't care about the SP's web server
certificate, and it doesn't
perform any verification other than with metadata, then the SP
wouldn't care about the IDP's
web server certificate either, and would only use metadata.

The IdP, in almost all deployment situations, doesn't care about the
certificates used by the web server that hosts the SP because that web
server isn't directly involved in any communication with the IdP. The
user will interface with the web server while carrying messages from
the IdP, but the trust comes from the signature on the assertion that
the user is carrying. An SSL tunnel exists between the user and the
SP's web server when delivering that assertion, but that just provides
a secure, private channel for that particular step.

Post by CHLOE SOWERS (BLOOMBERG/ 731 LEXIN)
Why make it so that the IDP only verifies via metadata, but the SP
verifies by metadata AND a web server certificate?

The SP only verifies by metadata as well. The difference is, in
backchannel communications between the SP and the IdP, the SP presents
its certificate directly, but the IdP's web server presents the
certificate on the IdP's behalf. That's because of the way each piece
was implemented: it's easy to initiate a query from the SP using the
CURL libraries, but challenging and uncommon for Java Servlets like
the IdP to receive and process web queries themselves.

Post by CHLOE SOWERS (BLOOMBERG/ 731 LEXIN)
How would I add the web server certificate to the IDP metadata? The SP fetches the IDP's
metadata via HTTP and saves it into a file.

You'd have to change the IdP's metadata wherever the SP is pulling it
from. The SP generates metadata dynamically based on its
configuration files, but the IdP generates it once during installation
and you need to make further changes yourself.

If you're using the built-in /idp/profile/Metadata/SAML handler, then
you need to modify the file that it's hosting, typically $IDP_HOME/
metadata/idp-metadata.xml. You'll see two certificates in there, and
you can replace those, or add your new certificate next to each of the
old ones.

Post by CHLOE SOWERS (BLOOMBERG/ 731 LEXIN)
I see multiple
<security:Credential id="IdPCredential"
xsi:type="security:X509Filesystem">
with different ids in relying-party.xml. Would I add the web server cert/key there?

Your IdP should have one credential in most deployment situations,
including this one. For rollover, you'd follow this general process:

1) Add new certificate to metadata
2) Change Apache's SOAP port (generally 8443) configuration to use
the new certificate in place of the old
3) Change the IdP's relying-party.xml to use the new certificate in
place of the old
4) Remove old certificate from metadata

Done.

I hope between Paul's response and my own, most of your questions were
answered.
Nate.

--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org