[Shib-Users] Problem with default credentials certificate on frech IdP installation

[David Hatanian]

Hi everyone,

  I was following the wiki installation documentation, and there seems to be a problem with the self-signed certificate "idp.crt" generated by the "install.sh" script : when it is parsed at the IdP launch, an exception is thrown : java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.

  The idp.crt was not in DER mode, so I converted it, but the exception remains. Has somebody already bumped into such a problem ?

Here is the exception in tomcat standard output :

java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.

        at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)

        at sun.security.util.DerValue.init(DerValue.java:365)

        at sun.security.util.DerValue.<init>(DerValue.java:320)

        at sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:1204)

        at java.security.KeyStore.load(KeyStore.java:1201)

        at org.apache.commons.ssl.KeyStoreBuilder.tryJKS(KeyStoreBuilder.java:450)

        at org.apache.commons.ssl.KeyStoreBuilder.parse(KeyStoreBuilder.java:416)

        at org.apache.commons.ssl.TrustMaterial.<init>(TrustMaterial.java:207)

        at org.apache.commons.ssl.TrustMaterial.<init>(TrustMaterial.java:160)

        at org.apache.commons.ssl.TrustMaterial.<init>(TrustMaterial.java:165)

        at org.apache.commons.ssl.TrustMaterial.<init>(TrustMaterial.java:170)

        at org.apache.commons.ssl.TrustMaterial.<clinit>(TrustMaterial.java:83)

        at org.opensaml.xml.security.x509.X509Util.decodeCertificate(X509Util.java:318)

        at edu.internet2.middleware.shibboleth.common.config.security.AbstractX509CredentialBeanDefinitionParser.parseCertificates(AbstractX509CredentialBeanDefinitionParser.java:108)

        at edu.internet2.middleware.shibboleth.common.config.security.AbstractX509CredentialBeanDefinitionParser.doParse(AbstractX509CredentialBeanDefinitionParser.java:72)

/////

java.security.KeyStoreException: failed to extract any certificates or private keys - maybe bad password?

        at org.apache.commons.ssl.KeyStoreBuilder.parse(KeyStoreBuilder.java:436)

        at org.apache.commons.ssl.TrustMaterial.<init>(TrustMaterial.java:207)

        at org.apache.commons.ssl.TrustMaterial.<init>(TrustMaterial.java:160)

        at org.apache.commons.ssl.TrustMaterial.<init>(TrustMaterial.java:165)

        at org.apache.commons.ssl.TrustMaterial.<init>(TrustMaterial.java:170)

        at org.apache.commons.ssl.TrustMaterial.<clinit>(TrustMaterial.java:83)

        at org.opensaml.xml.security.x509.X509Util.decodeCertificate(X509Util.java:318)

        at edu.internet2.middleware.shibboleth.common.config.security.AbstractX509CredentialBeanDefinitionParser.parseCertificates(AbstractX509CredentialBeanDefinitionParser.java:108)

        at edu.internet2.middleware.shibboleth.common.config.security.AbstractX509CredentialBeanDefinitionParser.doParse(AbstractX509CredentialBeanDefinitionParser.java:72)

        at org.springframework.beans.factory.xml.AbstractSingleBeanDefinitionParser.doParse(AbstractSingleBeanDefinitionParser.java:139)

        at org.springframework.beans.factory.xml.AbstractSingleBeanDefinitionParser.parseInternal(AbstractSingleBeanDefinitionParser.java:84)

        at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:56)

        at edu.internet2.middleware.shibboleth.common.config.BaseSpringNamespaceHandler.parse(BaseSpringNamespaceHandler.java:91)

        at edu.internet2.middleware.shibboleth.common.config.SpringConfigurationUtils.createBeanDefinition(SpringConfigurationUtils.java:176)

        at edu.internet2.middleware.shibboleth.common.config.SpringConfigurationUtils.parseInnerCustomElement(SpringConfigurationUtils.java:100)

        at edu.internet2.middleware.shibboleth.common.config.SpringConfigurationUtils.parseInnerCustomElements(SpringConfigurationUtils.java:116)

        at edu.internet2.middleware.shibboleth.common.config.relyingparty.RelyingPartyGroupBeanDefinitionParser.parseSecurityConfiguration(RelyingPartyGroupBeanDefinitionParser.java:101)

        at edu.internet2.middleware.shibboleth.common.config.relyingparty.RelyingPartyGroupBeanDefinitionParser.doParse(RelyingPartyGroupBeanDefinitionParser.java:62)

        at org.springframework.beans.factory.xml.AbstractSingleBeanDefinitionParser.parseInternal(AbstractSingleBeanDefinitionParser.java:84)

        at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:56) etc...

Regards,

David Hatanian

[Chad La Joie]

Did you change *anything* in the IdP configuration files? Can you read
the cert with something like openssl?

--
Chad La Joie
http://itumi.biz
trusted identities, delivered

[David Hatanian]

I did not change anything. I was able to read the certificate with "openssl x509 -text", and it was in pem format. I also ran "openssl verify" and the result was OK (openssl just said it was self-signed).

I converted it in DER but it didn't help.

2011/2/17 Chad La Joie <laj...@itumi.biz>

[Cantor, Scott E.]

> I did not change anything. I was able to read the certificate with "openssl
> x509 -text", and it was in pem format. I also ran "openssl verify" and the
> result was OK (openssl just said it was self-signed).

Is there something unusual about the hostname your box reports?

You can usually avoid using keystores with most containers and just use PKCS12 as a keystore "type", so you could try generating a keypair yourself and then convert that into PKCS12 with openssl for Java SSL use.

-- Scott

[Chad La Joie]

The stacktrace he gave isn't from the reading of the JKS file but the
PEM encoded key/cert file. So that won't fix it.

--

[Cantor, Scott E.]

> The stacktrace he gave isn't from the reading of the JKS file but the
> PEM encoded key/cert file. So that won't fix it.

Yes, I was suggesting starting over with a different key pair with a subject he controls. I can't think what else could break it but something about the cert content.

Since it's deriving the hostname on the fly from the box, my guess would be something's off about it.

-- Scott

[David Hatanian]

It seems to be an environment problem. I got the piece of code below working on my Windows dev environment and my Ubuntu virtual server, and the exception is thrown only on Ubuntu. So I'm thinking :

• Difference in text handling between OSes
• Difference in SSL library versions
• Difference in the JVM versions

As for the jar dependencies, I used the same in both environments (copied from the IdP lib folder).

Here is the code I ran :

package edu.internet2.middleware.shibboleth.common.config.security;

import java.security.cert.CertificateException;

import edu.internet2.middleware.shibboleth.common.config.security.FilesystemX509CredentialBeanDefinitionParser;;

public class TestParseCert  {

public static void main(String[] args) throws CertificateException{

FilesystemX509CredentialBeanDefinitionParser p = new FilesystemX509CredentialBeanDefinitionParser();

org.opensaml.xml.security.x509.X509Util.decodeCertificate(p.getEncodedCertificate("idp.crt.pem"));

}

}

2011/2/17 Cantor, Scott E. <cant...@osu.edu>

[David Hatanian]

OK, it was an openjdk6 issue. I installed the sun JRE and my IdP is now up and running.

Thank you for your help Chad and Scott !

David

2011/2/18 David Hatanian <dhat...@octo.com>

[Chad La Joie]

What version of OpenJDK? I run all my IdPs with OpenJDK and haven't had
any issues.

On 2/18/11 9:51 AM, David Hatanian wrote:
> OK, it was an openjdk6 issue. I installed the sun JRE and my IdP is now up
> and running.
> Thank you for your help Chad and Scott !
>
> David
>
> 2011/2/18 David Hatanian <dhat...@octo.com>
>
>> It seems to be an environment problem. I got the piece of code below
>> working on my Windows dev environment and my Ubuntu virtual server, and the
>> exception is thrown only on Ubuntu. So I'm thinking :
>>

>> - Difference in text handling between OSes
>> - Difference in SSL library versions
>> - Difference in the JVM versions

>>
>> As for the jar dependencies, I used the same in both environments (copied
>> from the IdP lib folder).
>>
>> Here is the code I ran :
>>
>> package edu.internet2.middleware.shibboleth.common.config.security;
>> import java.security.cert.CertificateException;
>> import
>> edu.internet2.middleware.shibboleth.common.config.security.FilesystemX509CredentialBeanDefinitionParser;;
>>
>> public class TestParseCert {
>> public static void main(String[] args) throws CertificateException{
>> FilesystemX509CredentialBeanDefinitionParser p = new
>> FilesystemX509CredentialBeanDefinitionParser();
>>
>> org.opensaml.xml.security.x509.X509Util.decodeCertificate(p.getEncodedCertificate("idp.crt.pem"));
>> }
>> }
>>
>>
>> 2011/2/17 Cantor, Scott E. <cant...@osu.edu>
>>
>>> The stacktrace he gave isn't from the reading of the JKS file but the
>>>> PEM encoded key/cert file. So that won't fix it.
>>>
>>> Yes, I was suggesting starting over with a different key pair with a
>>> subject he controls. I can't think what else could break it but something
>>> about the cert content.
>>>
>>> Since it's deriving the hostname on the fly from the box, my guess would
>>> be something's off about it.
>>>
>>> -- Scott
>>>
>>>
>>
>

--

[David Hatanian]

The java -version says :

java version "1.6.0_20"

OpenJDK Runtime Environment (IcedTea6 1.9.2) (6b20-1.9.2-0ubuntu1)

OpenJDK Client VM (build 19.0-b09, mixed mode, sharing)

I think it is the Ubuntu 10.10 default JRE.

2011/2/18 Chad La Joie <laj...@itumi.biz>

[Chad La Joie]

Okay, maybe that's why. RedHat/CentOS OpenJDK is still on build 17.

On 2/18/11 9:56 AM, David Hatanian wrote:
> The *java -version* says :