[prev in list] [next in list] [prev in thread] [next in thread]
List: shibboleth-users
Subject: Re: Certificate practices using IdP with MS AD LDAP
From: Daniel Fisher <dfisher () vt ! edu>
Date: 2013-04-24 18:45:26
Message-ID: CAFC6YwR4JYYETJjQ_dq64FW9C+FPH_+KUNURAqZQyiJh3cqe=A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, Apr 24, 2013 at 1:04 PM, David Bantz <dabantz@alaska.edu> wrote:
>
> On Wed, 24 Apr 2013, at 06:04 , Daniel Fisher <dfisher@vt.edu> wrote:
>
> ) Import the certificate for the Domain's private CA into an alternate
>> location for java trusted CA?
>>
>>
> This is my preferred solution. I like the trust dependencies to be
> declared in the configuration, even for certificates that would otherwise
> be trusted by default, and stored with the configuration. Storing
> certificate dependencies in cacerts invites problems associated with JVM
> upgrade and certificate expiration.
>
>
>> In either case, how do you ensure that both the private CA and other
>> well-known CAs have up-to-date certificates in that store?
>>
>
> CA expiration is typically greater than five years, and those transitions
> should be well communicated and planned.
>
>
> I'm probably missing something basic and would appreciate your helping me
> get clear:
>
> If I configure java to use an alternate store for trusted certificates,
> I'm told that bypasses trusting certificates in the default location. So
> how will the IdP appropriately trust certificates(or not) signed by well
> known CAs? Do you mean I need to import all the known root CAs into the
> alternate store and then actively manage that alternate store by checking
> for updates and revocations by all known CAs? That seems a big extra task.
>
>
I'm not suggesting you change the default, JVM wide trust settings. I'm
suggesting you configure trust specifically for your LDAP connections. In
particular this would mean configuring your attribute resolver with
a StartTLSTrustCredential:
https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverLDAPDataConnectorSee
SSL/TLS Support.
If you're using LDAP for authentication you would configure the JAAS module
as well:
sslSocketFactory="{trustCertificates=file:/path/to/my/trust.crt}"
Now your LDAP connections are using only the trust material you've supplied
in configuration and anything else using the default trust manager will
continue to function as normal.
--Daniel Fisher
[Attachment #5 (text/html)]
<div dir="ltr">On Wed, Apr 24, 2013 at 1:04 PM, David Bantz <span dir="ltr"><<a \
href="mailto:dabantz@alaska.edu" target="_blank">dabantz@alaska.edu</a>></span> \
wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
style="word-wrap:break-word"><div class="im"><br><div>
<div>On Wed, 24 Apr 2013, at 06:04 , Daniel Fisher <<a \
href="mailto:dfisher@vt.edu" target="_blank">dfisher@vt.edu</a>> \
wrote:</div><br><blockquote type="cite"><blockquote class="gmail_quote" \
style="font-family:Helvetica;font-size:medium;font-style:normal;font-variant:normal;fo \
nt-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px \
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
) Import the certificate for the Domain's private CA into an alternate location \
for java trusted CA?<br><br></blockquote><div \
style="font-family:Helvetica;font-size:medium;font-style:normal;font-variant:normal;fo \
nt-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br></div><div style="font-family:Helvetica;font-size:medium;font-style:normal;font-va \
riant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-w \
ebkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
This is my preferred solution. I like the trust dependencies to be declared in the \
configuration, even for certificates that would otherwise be trusted by default, and \
stored with the configuration. Storing certificate dependencies in cacerts invites \
problems associated with JVM upgrade and certificate expiration.</div>
<div style="font-family:Helvetica;font-size:medium;font-style:normal;font-variant:norm \
al;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
</div><blockquote class="gmail_quote" \
style="font-family:Helvetica;font-size:medium;font-style:normal;font-variant:normal;fo \
nt-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px \
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
In either case, how do you ensure that both the private CA and other well-known CAs \
have up-to-date certificates in that store?<br></blockquote><div \
style="font-family:Helvetica;font-size:medium;font-style:normal;font-variant:normal;fo \
nt-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br></div><div style="font-family:Helvetica;font-size:medium;font-style:normal;font-va \
riant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-w \
ebkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
CA expiration is typically greater than five years, and those transitions should be \
well communicated and planned.</div></blockquote></div><br></div><div>I'm \
probably missing something basic and would appreciate your helping me get \
clear:</div>
<div><br></div><div>If I configure java to use an alternate store for trusted \
certificates, I'm told that bypasses trusting certificates in the default \
location. So how will the IdP appropriately trust certificates(or not) signed by \
well known CAs? Do you mean I need to import all the known root CAs into the \
alternate store and then actively manage that alternate store by checking for updates \
and revocations by all known CAs? That seems a big extra task.</div>
<div><br></div></div></blockquote><div><br></div><div style>I'm not suggesting \
you change the default, JVM wide trust settings. I'm suggesting you configure \
trust specifically for your LDAP connections. In particular this would mean \
configuring your attribute resolver with a StartTLSTrustCredential:</div>
<div style><a href="https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverLDAPD \
ataConnector">https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverLDAPDataConnector</a> \
See SSL/TLS Support.<br></div><div style>
<br></div><div style>If you're using LDAP for authentication you would configure \
the JAAS module as well:</div><div \
style>sslSocketFactory="{trustCertificates=file:/path/to/my/trust.crt}"<br></div><div><br>
</div>
<div style>Now your LDAP connections are using only the trust material you've \
supplied in configuration and anything else using the default trust manager will \
continue to function as normal.</div><div style><br></div>
<div style>--Daniel Fisher</div><div style><br></div></div></div></div>
--
To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic