SubjectAltName of invalid type found

Openfire Openfire Support
1

I’'m trying to establish a secured s2s connection, but OpenFire 3.3.0 seems to have problem with my CACert and is unable to establish a secured connection (but “plain” works):

2007.05.09 20:17:28 SubjectAltName of invalid type found: [

[

Version: V3

Subject: CN=domain.invalid

Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

Key: Sun RSA public key, 1024 bits

modulus: 11181038977950435271605196033686[snip]

Validity: [From: Wed May 09 19:56:12 CEST 2007,

To: Mon Nov 05 18:56:12 CET 2007]

Issuer: EMAILADDRESS=support@cacert.org, CN=CA Cert Signing Authority, OU=http://www.cacert.org, O=Root CA

SerialNumber:

Certificate Extensions: 5

: ObjectId: 2.5.29.17 Criticality=false

SubjectAlternativeName [

DNSName: fbunet.de

Other-Name: Unrecognized ObjectIdentifier: 1.3.6.1.5.5.7.8.5

]

: ObjectId: 2.5.29.15 Criticality=false

KeyUsage [

DigitalSignature

Key_Encipherment

]

: ObjectId: 2.5.29.37 Criticality=false

ExtendedKeyUsages [

clientAuth

serverAuth

2.16.840.1.113730.4.1

1.3.6.1.4.1.311.10.3.3

]

: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false

AuthorityInfoAccess [

[accessMethod: 1.3.6.1.5.5.7.48.1

accessLocation: URIName: http://ocsp.cacert.org/]

]

: ObjectId: 2.5.29.19 Criticality=true

BasicConstraints:[

CA:false

PathLen: undefined

]

]

Algorithm:

Signature:

0000: 15 16 AC 3D 98 B6 53 7E 01 EB 1A 60 BC 3F E3 FE …=…S…`.?..

0010:

]

2007.05.09 20:18:10 EXCEPTION

java.net.SocketTimeoutException: Read timed out

at java.net.SocketInputStream.socketRead0(Native Method)

at java.net.SocketInputStream.read(Unknown Source)

at com.sun.net.ssl.internal.ssl.InputRecord.readFully(Unknown Source)

at com.sun.net.ssl.internal.ssl.InputRecord.read(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(Unknown Source)

at com.sun.net.ssl.internal.ssl.AppInputStream.read(Unknown Source)

at org.mortbay.io.ByteArrayBuffer.readFrom(ByteArrayBuffer.java:168)

at org.mortbay.io.bio.StreamEndPoint.fill(StreamEndPoint.java:99)

at org.mortbay.jetty.bio.SocketConnector$Connection.fill(SocketConnector.java:190)

at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:277)

at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:203)

at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)

at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:217)

at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)

2007.05.09 20:18:10 EOF

2

Hi

I also get this problem. The issue is discussed briefly in this thread http://www.igniterealtime.org/forum/thread.jspa?messageID=140181&#140181 The problem seems to have arisen in 3.21. but t was unclear if it was XMPP certificate or Wildfire that was causing the problem.

I haven’'t seen any more about the problem but I was thinking about raising it again myself. I would really like to see this fixed as I would much prefer secured conections even though it is difficult to find many servers where it works!

Gato can you let us know if you have found out any more about this?

BR

David

3

Hey guys,

A certificate may have several subjectAltNames and each one could be of different types (for different usages). Openfire will print the SubjectAltName of invalid type found debug message when a subjectAltName that does not contain the XMPP spec is found. This is not an error but just debugging information. The server iterates on all the subjectAltNames trying to find the one that contains XMPP info and if none was found then it will use the info contained in the common name.

Having said that, if the certificate has an incorrect CM and no subjectAltName with XMPP info or with XMPP info but with incorrect data (e.g. incorrect XMPP domain) then the server will fail to accept the certificate of the remote server. As a simple test, you can disable certificates verification and see if TLS is still used. To disable cert verification set the system property xmpp.server.certificate.verify to false (no need to restart the server). If TLS is failing to work then the error is something else.

– Gato

4

OK it looks like I wasn’'t helping matter here! I can see that there are other errors that I am not getting. Sorry for any confusion!

Unfortunately I still have a problem with getting some secured connections and invalid SubAltName appeared to be the only common factor. I guess I should start another thread once I have had time to look into it more thoroughly. One of the problems is that it is very difficult to test what is happening with S2S security without being able to see both sides of the connection. I guess one option would be to set up another server for testing purposes. I wonder if ignite realtime has ever thought about providing a server that people could use to test their S2S configuration against? I realise that it could cause some headaches but there do seem to be a lot of problems in this area and it might save some effort in the longer term.

BR

David

5

Hey David,

The way I tested things was by running 2 servers in my network. That way I was able to collect the info I needed on each server and even debug them. Having said that, we have a new feature request filed in Jira JM-382 related to your suggestion. Feel free to vote for it to raise its priority.

– Gato

6

Thanks Gato

I am seriously considering setting up another server to do the testing although it would be quite time-consuming to do it properly as I would really need to get another certificate, etc. The new feature request sounds interesting. It is quite frustrating as virtually everthing seem to be working. I can get a secured outgoing connection to jabber.org but not incoming. Some other servers fail completely even when I accept self-signed certificates. I don’'t have problems with plalntext and dialback. Anyway I should really start another thread for my issue!

BR

David

7

The main question is: Why doesn’'t Openfire create a certificate that complies to rfc3920 14.2?

“a subjectAltName extension of type “xmpp” MUST be used as the identity”