Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

ssl-handshake fails with scandinavian chars in client certificate

2 views
Skip to first unread message

Igor Styrman

unread,
Jun 2, 2004, 11:05:34 AM6/2/04
to

Hello,

We've run into a problem with 2-way-ssl and certificates that have scandinavian
characters in the subject. The problem cert is used as client-certificate for
authentication and it goes like this:

1. Client surfs with http in our site, until clicks https-link that will immediately
start the ssl-handshake
2. Server presents it's trusted cert-list fine
3. PIN is being asked fine
4. Next the request processing stops on the exception below and nothing will happen
on the client side.

Certs without these הצו -chars work fine, so our guess is that they cause it,
but the certs ought to be according to specs: name-fields encoding is UTF-8 according
to RFC 2459 from year 1999. A failing example-cert is also below.

Would this be a problem with the certificate rather than BEA-implementation?

Same behavior on Windows and Solaris Weblogic 8.11 as such and with SP2 (and with
sp2 + CASE_ID_NUM: 501454 hotfix).

Best Regards,

Igor Styrman

<avalable(): 20303264 : 0 + 0 = 0>
<write ALERT offset = 0 length = 2>
<SSLIOContextTable.removeContext(ctx): 1765100>
PM EEST><SSLListenThread.Default> <<WLS Kernel>> <> <000000> <Filtering JSSE
SSLSocket>
PM EEST><SSLListenThread.Default> <<WLS Kernel>> <> <000000> <SSLIOContextTable.addContext(ctx):
6487148>
PM EEST><SSLListenThread.Default> <<WLS Kernel>> <> <000000> <SSLSocket will
be Muxing>
PM EEST><SSLListenThread.Default> <<WLS Kernel>> <> <000000> <SSLIOContextTable.findContext(is):
11153746>
<SSLFilter.isActivated: false>
<isMuxerActivated: false>
<SSLFilter.isActivated: false>
<21647856 readRecord()>
<21647856 SSL Version 2 with no padding>
<21647856 SSL3/TLS MAC>
<21647856 received SSL_20_RECORD>
<HANDSHAKEMESSAGE: ClientHelloV2>
<write HANDSHAKE offset = 0 length = 58>
<write HANDSHAKE offset = 0 length = 1789>
<Converting principal: OU=Class 4 Public Primary Certification Authority, O="VeriSign,
Inc.", C=US>
<Converting principal: CN=SHP ROOT CA, O=SHP, C=FI>
<Converting principal: CN=topsel, O=Fujitsu Services Oy, C=FI>
<Converting principal: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions,
Inc.", O=GTE Corporation, C=US>
<Converting principal: CN=SatShp CA, O=Satakunnan sairaanhoitopiiri, C=FI>
<Converting principal: OU=Class 1 Public Primary Certification Authority, O="VeriSign,
Inc.", C=US>
<Converting principal: EMAILADDRESS=persona...@thawte.com, CN=Thawte Personal
Basic CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town,
ST=Western Cape, C=ZA>
<Converting principal: EMAILADDRESS=personal...@thawte.com, CN=Thawte Personal
Freemail CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town,
ST=Western Cape, C=ZA>
<Converting principal: OU=Class 3 Public Primary Certification Authority, O="VeriSign,
Inc.", C=US>
<Converting principal: CN=GTE CyberTrust Root, O=GTE Corporation, C=US>
<Converting principal: EMAILADDRESS=server...@thawte.com, CN=Thawte Server
CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western
Cape, C=ZA>
<Converting principal: EMAILADDRESS=personal...@thawte.com, CN=Thawte Personal
Premium CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town,
ST=Western Cape, C=ZA>
<Converting principal: EMAILADDRESS=premium...@thawte.com, CN=Thawte Premium
Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape
Town, ST=Western Cape, C=ZA>
<Converting principal: OU=Secure Server Certification Authority, O="RSA Data Security,
Inc.", C=US>
<Converting principal: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore,
C=IE>
<Converting principal: CN=Fujitsu Test CA, O=Fujitsu Services Oy, C=FI>
<Converting principal: CN=GTE CyberTrust Root 5, OU="GTE CyberTrust Solutions,
Inc.", O=GTE Corporation, C=US>
<Converting principal: CN=PSHP CA, O=Pirkanmaan sairaanhoitopiiri, C=FI>
<Converting principal: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust,
O=Baltimore, C=IE>
<Converting principal: OU=Class 2 Public Primary Certification Authority, O="VeriSign,
Inc.", C=US>
<write HANDSHAKE offset = 0 length = 2409>
<write HANDSHAKE offset = 0 length = 4>
<SSLFilter.isActivated: false>
<isMuxerActivated: false>
<SSLFilter.isActivated: false>
<21647856 readRecord()>
<21647856 SSL3/TLS MAC>
<21647856 received HANDSHAKE>
<HANDSHAKEMESSAGE: Certificate>
PM EEST> <Error> <Kernel> <> <satshpeduServer> <ExecuteThread: '14' for queue:
'weblogic.kernel.Default'> <<WLS Kernel>> <> <BEA-000802> <ExecuteRequest failed
java.lang.NullPointerException: Could not set value for ASN.1 string object..
java.lang.NullPointerException: Could not set value for ASN.1 string object.
at com.certicom.security.asn1.ASN1String.setValue(Unknown Source)
at com.certicom.security.asn1.ASN1String.setBufferTo(Unknown Source)
at com.certicom.security.asn1.DERInputStream.decodeString(Unknown Source)
at com.certicom.security.asn1.ASN1String.decode(Unknown Source)
at com.certicom.security.pkix.AttributeTypeAndValue.decodeContents(Unknown Source)
at com.certicom.security.asn1.DERInputStream.decodeStructured(Unknown Source)
at com.certicom.security.asn1.DERInputStream.decodeSequence(Unknown Source)
at com.certicom.security.asn1.ASN1Sequence.decode(Unknown Source)
at com.certicom.security.asn1.ASN1SetOf.decodeContents(Unknown Source)
at com.certicom.security.asn1.DERInputStream.decodeStructured(Unknown Source)
at com.certicom.security.asn1.DERInputStream.decodeSetOf(Unknown Source)
at com.certicom.security.asn1.ASN1SetOf.decode(Unknown Source)
at com.certicom.security.asn1.ASN1SequenceOf.decodeContents(Unknown Source)
at com.certicom.security.asn1.DERInputStream.decodeStructured(Unknown Source)
at com.certicom.security.asn1.DERInputStream.decodeSequence(Unknown Source)
at com.certicom.security.asn1.ASN1Sequence.decode(Unknown Source)
at com.certicom.security.pkix.Name.decodeContents(Unknown Source)
at com.certicom.security.asn1.ASN1Choice.decode(Unknown Source)
at com.certicom.security.pkix.TBSCertificate.decodeContents(Unknown Source)
at com.certicom.security.asn1.DERInputStream.decodeStructured(Unknown Source)
at com.certicom.security.asn1.DERInputStream.decodeSequence(Unknown Source)
at com.certicom.security.asn1.ASN1Sequence.decode(Unknown Source)
at com.certicom.security.pkix.Certificate.decodeContents(Unknown Source)
at com.certicom.security.asn1.DERInputStream.decodeStructured(Unknown Source)
at com.certicom.security.asn1.DERInputStream.decodeSequence(Unknown Source)
at com.certicom.security.asn1.ASN1Sequence.decode(Unknown Source)
at com.certicom.security.asn1.ASN1Type.decode(Unknown Source)
at com.certicom.security.cert.internal.x509.X509V3CertImpl.<init>(Unknown Source)
at com.certicom.tls.record.handshake.MessageCertificate.<init>(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeMessage.create(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessages(Unknown
Source)
at com.certicom.tls.record.ReadHandler.interpretContent(Unknown Source)
at com.certicom.tls.record.ReadHandler.readRecord(Unknown Source)
at com.certicom.tls.record.ReadHandler.readUntilHandshakeComplete(Unknown Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.completeHandshake(Unknown
Source)
at com.certicom.net.ssl.CerticomContextWrapper.forceHandshakeOnAcceptedSocket(Unknown
Source)
at weblogic.t3.srvr.SSLListenThread$1.execute(SSLListenThread.java:514)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)


-----BEGIN CERTIFICATE-----
MIID+zCCAuOgAwIBAgIDFm/PMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNVBAYTAkZJ
MRwwGgYDVQQKExNGdWppdHN1IFNlcnZpY2VzIE95MRgwFgYDVQQDEw9GdWppdHN1
IFRlc3QgQ0EwHhcNMDQwNjAyMTE1MjE4WhcNMDYwNjAyMTIyMjE4WjB3MQswCQYD
VQQGEwJGSTEQMA4GA1UEChMHRnVqaXRzdTEgMB4GA1UEAwwXSMO2bG3DtmzDpGlu
ZW4gw4VrZSAwMDExDDAKBgNVBAUTAzAwMTEXMBUGA1UEBAwOSMO2bG3DtmzDpGlu
ZW4xDTALBgNVBCoMBMOFa2UwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAO44
Zm31uJb8048/6PByPyXzaW3gCz1mT02TuwVtjMRJ4ObbFCqMGC+YosA2kNKoW0Ef
C+YlKNqhvaid0bATQefdSHVQhzFL3HFIfZc3ONAJQ/U+I6W69r2JePoCvZppknmC
YrnCCDx3Ap27B7v57f/XTmdpiB8IdiCTl3PnV78PAgMBAAGjggFEMIIBQDAfBgNV
HSMEGDAWgBT8T+xYc3T6j89O8cZ4hC9r1e9DojAdBgNVHQ4EFgQUtS4z8K26uW2d
IeJ3aelDnqnkBnYwCwYDVR0PBAQDAgSwMFMGA1UdEQRMMEqgKwYKKwYBBAGCNxQC
A6AdDBtha2UuaG9sbW9sYWluZW5AZnVqaXRzdS5jb22BG2FrZS5ob2xtb2xhaW5l
bkBmdWppdHN1LmNvbTB9BgNVHR8EdjB0MHKgcKBuhmxsZGFwOi8vMjEyLjI0Ni4y
MjIuMTQyOjM4OS9DTj1GdWppdHN1JTIwVGVzdCUyMENBLE89RnVqaXRzdSUyMFNl
cnZpY2VzJTIwVGVzdCxDPUZJP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3QwHQYD
VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBQUAA4IBAQAZ
KV3Og/y6zUOMwZGswUxAne5fe4Ab70bmX+z49MVeA0dfdQwQdR9GwFVF+fcK+q0T
3Lmcwpm5KiHWYoIOxPb6MqTTWxV7HSXWr7A7P4BbTGxsujpUULcmQGQFAd69R0Ur
JFDwYnDEP2+4RzrvlP6AWspyHJePYmCt9h3JfxYAqVLTL0suO1uh8hgtStujmqsI
0WNCfnQ+sURdDzp6WpVFcxFQa5aAcyx9sWWqV5Ta5l6JTCmoHth7qoV3BtUKv4+z
SqIHKA1ixrvlhqWkjYxg51N6ihbbR5shBRRinAqRIQjTzXmun2wJzwNigt4zWiNg
tvrGCMOrvrb5QTxVtLNr
-----END CERTIFICATE-----

Pavel

unread,
Jun 2, 2004, 7:30:05 PM6/2/04
to

Sounds like a bug in certicom code. It should support UTF8String.
I'd file a support case.
You might be able to use BMPString instead as a workaround.

Pavel.

Ari Räisänen

unread,
Jun 3, 2004, 6:57:40 AM6/3/04
to

Thanks again, Pavel!

I'm filing a support case about this. You talked about a workaround (BMPString).
Could you be more spesific? I haven't talked about this issue with Igor yet.

Regards,
Ari

Pavel

unread,
Jun 3, 2004, 10:54:07 AM6/3/04
to

BMPString is another asn1 type that can be used for certificate attributes with
non-ascii characters. The workaround is simply to use the BMPString instead of
UTF8String for that subject name attribute in the certificate request. This off-course
assumes that you can replace the certificate, and have control over what asn1
type is used for the subject name attributes in the certificate request (via a
tool options, or by generating the request yourself), so it is probably not applicable.

Pavel.

>>>Certs without these äöå -chars work fine, so our guess is that they

Ari Räisänen

unread,
Jun 4, 2004, 2:32:04 AM6/4/04
to

As you guessed, replacing the certificates is not applicable at the moment. We'd
have to replace a lot of smart cards that are delivered to the end users already.

Anyway, I filed a support case and hopefully we'll get the solution soon.

0 new messages