<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 2/17/16 2:21 PM, Paul Hethmon wrote:<br>
</div>
<blockquote
cite="mid:157ED2F7-EE88-4755-816C-876BF9D013D8@clareitysecurity.com"
type="cite">
<pre wrap="">
Without commenting on how clueless MS support is, they are asking me to try a CA signed certificate for the SAML signing certificate (instead of the normal self-signed cert created at installation). So some questions in case someone else has had to bang their head against the O365 wall:</pre>
</blockquote>
<br>
I know literally zero about Office 365, so I have no idea how their
trust works and what they really require. Do you supply a metadata
XML document? Do you upload a key + other info to a mgmt UI on the
MS side? <br>
<br>
<blockquote
cite="mid:157ED2F7-EE88-4755-816C-876BF9D013D8@clareitysecurity.com"
type="cite">
<pre wrap="">
1. If I put in a CA signed certificate as my public key, is there a need to include intermediate certificates? At least as far as my published IdP metadata.</pre>
</blockquote>
<br>
Well, it depends on whether they actually evaluate the certificate
chain (like our PKIX trust engines) or just eval the public key only
(like out "explicit key" trust engines). In general: If they do in
fact eval the certificate chain via PKIX, then yes, they have to
have all the certs in the chain, one way or another, in order to
construct the path back to the trusted root. <br>
<br>
With PKIX trust (XML Signatures, TLS, etc) it is generally
considered good form (and often required) for the wielder of an
entity cert to also include all necessary intermediate certs up but
not including the trust root, when they wield the cert. In XML
Signature, that is done via supplying them in the signature's
KeyInfo, however (i.e. not in the metadata). OpenSAML/ Shib IdP can
do that. IIRC you supply all the intermediates as part of the
signing credential you configure.<br>
<br>
With our PKIX trust model, however, one actually doesn't put *any*
IdP/SP entity cert in the *metadata*, much less intermediate certs.
Just trusted name(s) for certs wielded by the entity. Trusted roots
are supplied via a custom KeyInfo extension. So I have no idea what
MS expects, or how their model works. <br>
<br>
<br>
<br>
<blockquote
cite="mid:157ED2F7-EE88-4755-816C-876BF9D013D8@clareitysecurity.com"
type="cite">
<pre wrap="">
2. MS support keeps wanting to see a Shib log file that is usually in /var/log/shibboleth/shibd.log. Isn’t that the default location for the Shib SP log file?</pre>
</blockquote>
<br>
Yeah, that's not a Shib IdP log file, that's SP.<br>
<br>
<blockquote
cite="mid:157ED2F7-EE88-4755-816C-876BF9D013D8@clareitysecurity.com"
type="cite">
<pre wrap="">
3. Any troubleshooting tips?
</pre>
</blockquote>
<br>
Unfortunately no, since I've never touched Office 365. But if there
is some specific error message that indicates where the problem is,
that would be helpful to know. Meaning: Are you sure the problem is
with the SAML signature?<br>
<br>
</body>
</html>