Replacing self-signed SSL Certificate

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Replacing self-signed SSL Certificate

Brinkman, Jeremy

Hi All,

Our IdP was working just fine until we decided to replace the existing self-signed SSL certificate with one from a trusted third party. 

 

After receiving the certificate from the trusted third party, I replaced the old certificate.  Now, I am receiving the following ERROR in the log file:

 

14:34:03.940 - ERROR [edu.internet2.middleware.shibboleth.common.config.BaseService:187] - Configuration was not loaded for shibboleth.RelyingPartyConfigurationManager service, error creating components.  The root cause of this error was: org.apache.commons.ssl.ProbablyNotPKCS8Exception: asn1 parse failure: java.io.IOException: DER length more than 4 bytes

 

Does anyone have an idea where to go from here?

 

Thanks,

Jeremy

 

Jeremy Brinkman

Director of Administrative Systems

University of Northwestern Ohio

 

Reply | Threaded
Open this post in threaded view
|

RE: Replacing self-signed SSL Certificate

Cantor, Scott E.
> Our IdP was working just fine until we decided to replace the existing
self-
> signed SSL certificate with one from a trusted third party.

I think you probably want to start with that...who's the third party? If a
particular federation imposes a certificate on you, then they might have
some clue as to what they put in the certificate that broke it.

Otherwise there's no reason to be using this certificate. The worst thing
you can do is use a commercial certificate. There's no upside and huge
downside, so just don't do it.

> Does anyone have an idea where to go from here?

The error is presumably in the certificate itself, but I would start with
whether you need to use it in the first place. InCommon, for one example,
does issue certificates you have to use right now but I'm not aware of any
issues reading them with Java.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: Replacing self-signed SSL Certificate

Brinkman, Jeremy
The "Idp is working just fine" statement was misleading.  We have not yet joined InCommon but will do so soon.  Our IdP is authenticating and returning attributes on testshib.org only.

When we join InCommon, will they be issuing us a certificate as part of the setup and annual fees?

Jeremy


-----Original Message-----
From: Scott Cantor [mailto:[hidden email]]
Sent: Thursday, January 08, 2009 3:01 PM
To: [hidden email]
Subject: RE: [Shib-Users] Replacing self-signed SSL Certificate

> Our IdP was working just fine until we decided to replace the existing
self-
> signed SSL certificate with one from a trusted third party.

I think you probably want to start with that...who's the third party? If a
particular federation imposes a certificate on you, then they might have
some clue as to what they put in the certificate that broke it.

Otherwise there's no reason to be using this certificate. The worst thing
you can do is use a commercial certificate. There's no upside and huge
downside, so just don't do it.

> Does anyone have an idea where to go from here?

The error is presumably in the certificate itself, but I would start with
whether you need to use it in the first place. InCommon, for one example,
does issue certificates you have to use right now but I'm not aware of any
issues reading them with Java.

-- Scott


Reply | Threaded
Open this post in threaded view
|

Re: Replacing self-signed SSL Certificate

Brent Putman
In reply to this post by Cantor, Scott E.


Scott Cantor wrote:
>> Does anyone have an idea where to go from here?
>>    
>
> The error is presumably in the certificate itself, but I would start with
> whether you need to use it in the first place. InCommon, for one example,
> does issue certificates you have to use right now but I'm not aware of any
> issues reading them with Java.
>
>  

Actually, since the exception indicates that the problem is with data
it's parsing which it thinks isn't PKCS8, that perhaps implies an issue
with the private key, not the cert.  Perhaps you mistakenly pasted the
base64 blob of the new certificate into the PrivateKey element (rather
than the Certificate element), or otherwise corrupted the PrivateKey
element data (extra character inserted, etc), or something like that?

I'm also not aware of any issues with Java reading certs from any
particular source, with extensions, etc.

--Brent

Reply | Threaded
Open this post in threaded view
|

RE: Replacing self-signed SSL Certificate

Cantor, Scott E.
In reply to this post by Brinkman, Jeremy
> When we join InCommon, will they be issuing us a certificate as part of
the
> setup and annual fees?

Once you enroll as an administrator and request the certificate, yes. At the
moment anyway. Eventually you'll upload a certificate you choose into your
metadata.

Based on what Brent said sounds like it's the key anyway, but my point
stands that there's no reason to use anything in the IdP that isn't
dependent on the federation's rules other than the browser-facing part which
is the web server's job.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: Replacing self-signed SSL Certificate

Brinkman, Jeremy
Thanks Scott & Brent.  I think I understand the configuration better now.  This in a testament to my inexperience with Shibboleth:  I was attempting to use a third-party certificate for both the browser-facing and IdP components.

I separated the two certificates and it is functioning as expected now.
Thanks again,
Jeremy

-----Original Message-----
From: Scott Cantor [mailto:[hidden email]]
Sent: Thursday, January 08, 2009 3:34 PM
To: [hidden email]
Subject: RE: [Shib-Users] Replacing self-signed SSL Certificate

> When we join InCommon, will they be issuing us a certificate as part of
the
> setup and annual fees?

Once you enroll as an administrator and request the certificate, yes. At the
moment anyway. Eventually you'll upload a certificate you choose into your
metadata.

Based on what Brent said sounds like it's the key anyway, but my point
stands that there's no reason to use anything in the IdP that isn't
dependent on the federation's rules other than the browser-facing part which
is the web server's job.

-- Scott