<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:10.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Based on my experience with vendors saying one thing and doing another, it's likely it's just using the old pub cert still. The name check failure is likely unrelated. It is also an INFO line.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">From my experience the CN of the cert doesn't tend to matter. If you're not sure, you could simply add both pub certs to the SP metadata in parallel until the vendor assures you that they removed the old one.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">But vendors often don't understand SAML well enough to do this well.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- Steve<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">users <users-bounces@shibboleth.net> on behalf of Mark Cairney via users <users@shibboleth.net><br>
<b>Date: </b>Thursday, April 7, 2022 at 9:37 AM<br>
<b>To: </b>users@shibboleth.net <users@shibboleth.net><br>
<b>Cc: </b>Mark Cairney <Mark.Cairney@ed.ac.uk><br>
<b>Subject: </b>Credential failed name check error upon updating SP certificate<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Hi,<br>
<br>
We've recently been working with a vendor who are upgrading the<br>
certificate in their metadata from an old SHA1 cert to a SHA256 cert.<br>
<br>
However we got the following error when logging in using the new cert:<br>
<br>
2022-04-06 17:57:55,973 - INFO<br>
[org.opensaml.security.x509.impl.BasicX509Credent<br>
ialNameEvaluator:297] - [129.215.16.48]|Credential failed name check:<br>
[subjectNa<br>
me='CN=careerhub.ed']<br>
2022-04-06 17:57:55,974 - WARN<br>
[net.shibboleth.idp.profile.impl.WebFlowMessageHa<br>
ndlerAdaptor:197] - [129.215.16.48]|Profile Action<br>
WebFlowMessageHandlerAdaptor:<br>
Exception handling message<br>
org.opensaml.messaging.handler.MessageHandlerException: Validation of<br>
protocol m<br>
essage signature failed<br>
at org.opensaml.saml.common.binding.security.impl.SAMLProtocolMessageXML<br>
SignatureSecurityHandler.doEvaluate(SAMLProtocolMessageXMLSignatureSecurityHandl<br>
er.java:147)<br>
<br>
We reverted back to the old certificate and the SP started working again<br>
however we're a bit confused as to why the IdP doesn't like the new<br>
certificate.<br>
<br>
The details of the new cert are:<br>
<br>
<br>
Certificate:<br>
Data:<br>
Version: 3 (0x2)<br>
Serial Number:<br>
1d:15:be:5e:b3:f5:0f:94:46:f8:27:a7:86:30:59:76<br>
Signature Algorithm: sha256WithRSAEncryption<br>
Issuer: CN = careerhub-ed<br>
Validity<br>
Not Before: Oct 11 14:31:16 2021 GMT<br>
Not After : Oct 11 14:41:16 2041 GMT<br>
Subject: CN = careerhub-ed<br>
Subject Public Key Info:<br>
Public Key Algorithm: rsaEncryption<br>
RSA Public-Key: (2048 bit)<br>
Modulus:<br>
00:ab:38:08:1a:06:f6:c5:da:b5:46:17:9e:c1:85:<br>
4f:e5:80:99:6e:f8:79:c1:ae:83:29:09:d0:b8:4c:<br>
a6:65:a9:f1:cc:54:2e:ab:66:88:43:a3:8f:11:23:<br>
6e:ab:68:90:2a:2e:48:24:f7:eb:9e:67:7f:cc:c7:<br>
d9:1c:f1:49:83:0e:bc:88:6f:69:41:1e:e2:95:ec:<br>
8a:68:86:3e:60:d9:67:ba:73:5c:af:f3:a8:de:f6:<br>
76:2a:70:48:3a:bf:b1:3d:4c:c2:35:84:f1:57:f8:<br>
92:29:22:47:20:09:a1:a6:52:b4:d1:41:31:a1:1a:<br>
0b:61:f0:2d:b7:cc:cc:a5:60:54:48:38:20:83:91:<br>
e0:88:2c:91:a5:e3:ef:5e:cf:7d:e8:05:f1:ff:26:<br>
35:e9:2f:be:9f:23:89:03:97:e4:b5:6c:84:07:d0:<br>
d6:a5:04:ef:cc:f9:68:0f:69:f1:13:87:9d:09:ae:<br>
8c:42:24:75:7d:fb:51:98:7e:fa:34:56:47:38:d9:<br>
41:34:7b:48:9f:c5:65:56:e4:55:05:e4:dc:6d:2c:<br>
e1:5a:3c:1a:d2:d8:03:60:53:58:d4:17:c9:a5:84:<br>
dc:15:3f:f7:d9:17:25:46:75:50:ac:67:cd:d2:13:<br>
c6:32:22:f8:39:13:73:f5:88:fb:62:02:fc:ef:c8:<br>
f7:15<br>
Exponent: 65537 (0x10001)<br>
X509v3 extensions:<br>
X509v3 Key Usage: critical<br>
Digital Signature, Key Encipherment<br>
X509v3 Extended Key Usage:<br>
TLS Web Client Authentication, TLS Web Server Authentication<br>
X509v3 Subject Alternative Name:<br>
DNS:careerhub-ed<br>
X509v3 Subject Key Identifier:<br>
95:98:29:82:36:42:53:C6:E3:28:15:94:1B:EF:01:7E:D9:0E:EA:96<br>
Signature Algorithm: sha256WithRSAEncryption<br>
78:ad:a1:13:1f:80:4e:23:cb:79:77:78:c5:4e:be:07:0f:1b:<br>
bf:b5:2e:e7:da:38:37:9f:3c:45:15:31:8a:37:4e:77:ee:ea:<br>
34:7d:0e:a1:26:7e:b0:27:43:dc:bf:cc:9b:2d:ae:fc:6c:86:<br>
f9:af:85:ac:97:a7:f4:27:92:ea:ec:aa:20:9d:6d:73:12:9f:<br>
de:aa:46:a4:52:7c:ed:93:50:1c:32:c0:62:af:43:55:dc:93:<br>
7a:57:66:d0:6d:8f:ae:31:a6:3b:85:2f:f9:60:95:f0:fb:06:<br>
a6:c0:37:3c:d7:a7:ff:ad:a0:ff:51:82:32:ef:97:02:97:60:<br>
b6:b0:47:f7:e4:a3:47:1a:6e:dd:b8:66:53:11:bd:fd:0b:98:<br>
06:1b:2c:46:e9:e1:bc:b7:76:40:0b:4a:a3:3f:67:65:11:fa:<br>
15:7f:48:f6:df:29:c3:e4:95:1b:57:09:6e:ac:53:a2:86:5a:<br>
0a:c4:66:a9:45:2c:fe:e2:19:c0:41:24:58:d5:6f:a4:9a:8d:<br>
27:59:54:e3:d4:92:18:fe:67:50:9e:d0:89:ce:2f:8f:5b:e8:<br>
78:7c:c9:24:07:a3:a4:90:24:48:32:64:02:29:31:b4:7a:77:<br>
ef:01:a3:0a:0c:d6:2b:b1:28:5a:f0:74:07:66:37:25:d8:60:<br>
57:e9:7a:9c<br>
<br>
<br>
The only thing we could think of is that the IdP is being picky about<br>
the CN being a FQDN and having a matching Subject AltName in place<br>
having had a quick look at the OpenSAML<br>
"BasicX509CredentialNameEvaluator" class but it would be good to know<br>
what triggers a failure in this and if there are differing requirements<br>
in place for signing and encryption keys. We've got this working on Dev<br>
now using a fully-qualified domain name as the CN and DNS<br>
SubjectAltName. We did try a new cert with the same Subject as the old<br>
one i.e. "CN= careerhub-ed" but this also failed.<br>
<br>
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.<br>
-- <br>
For Consortium Member technical support, see <a href="https://urldefense.com/v3/__https:/shibboleth.atlassian.net/wiki/x/ZYEpPw__;!!IBzWLUs!AEMvSFvC2yJH01EA9-9DkAfhAwna7llTJyk4LV2cpky9iqFQDV8ukZ6ntb6AJA$">
https://urldefense.com/v3/__https://shibboleth.atlassian.net/wiki/x/ZYEpPw__;!!IBzWLUs!AEMvSFvC2yJH01EA9-9DkAfhAwna7llTJyk4LV2cpky9iqFQDV8ukZ6ntb6AJA$</a>
<br>
To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net<o:p></o:p></span></p>
</div>
</div>
</body>
</html>