<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 3/24/15 1:36 PM, Michael O Holstein
wrote:<br>
</div>
<blockquote cite="mid:1427218852063.88626@csuohio.edu" type="cite">
<pre wrap="">I suspect the answer to my question is along these lines ...
[conf/credentials.xml]
<!-- SHA1 credentials -->
<bean id= "SHA1SecurityConfig"
class="net.shibboleth.idp.profile.spring.factory.BasicX509CredentialFactoryBean"
p:privateKeyResource="%{idp.sha1signing.key}"
p:certificateResource="%{idp.sha1signing.cert}"
p:entityId-ref="entityID" />
the path must be specified explicity somewhere because the keys/certs of those names are in the same location
Could not resolve placeholder 'idp.sha1signing.cert' in string value "%{idp.sha1signing.cert}"; nested exception is java.lang.IllegalArgumentException: Could not resolve placeholder 'idp.sha1signing.cert' in string value "%{idp.sha1signing.cert}"
</pre>
</blockquote>
<br>
<br>
Yes, that's essentially how you'd define a new credential, which
you'd then reference in the signing config, except: Those property
names don't just magically exist. You'd have to define them in a
property file somewhere. But you really don't need to use full
properties there. We use those to simplify and abstract out config
for deployers, but you can just put literal values there. Or
better, you might want to make the path relative to idp.home and use
a form similar to what you see in idp.properties, e.g. <tt>"</tt>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<tt>%{idp.home}/credentials/custom-signing.crt"</tt>.<br>
<br>
But as I said previously, you certainly don't need to use a custom
credential just because you want to use SHA-1 signing algorithms.
That's only necessary if the relying party in question is not a
Shibboleth SP and has some weird requirement/limitation that it
won't accept the default signing cert, e.g. perhaps because it's
using a PKIX trust model and has an older PKIX library that doesn't
support SHA-256 certs. Or something like that. Many SP's are going
to use an "explicit key" trust model however, where the cert
algorithms are completely irrelevant.<br>
</body>
</html>