# Pidgin-Jabber with SSL Configuration Problem



## rtwingfield (Sep 2, 2011)

I have upgraded the Pidgin client to v2.10.0 (same problems as with prior version v2.7+):
Jabber is v2.2.14 installed from the Ports.

Note that Pidgin v2.7 was working as configured with Jabber v2.2.11.


Pidgin configured as using old style SSL and port 5223 results with the log indicating that it is attempting to connect via port 5223, but the SSL handshake fails.  The same results if the designated port is 5222!

...from the Pidgin log

```
(07:30:23) proxy: Connected to archaxis.net:5223.
[color="Red"](07:30:23) nss: Handshake failed  (-5938)[/color]
```


If Pidgin is configured to use encryption if available and configured to point to port 5223, then it does this:

```
(07:54:39) proxy: Connecting to archaxis.net:5222 with no proxy[font="Arial"][color="Blue"]
. . .this seems strange because port 5223 was specified in the config, but
continues the conversation with Jabber until it eventually disconnects[/color][/font]
(07:54:39) jabber: Recv (51): <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
(07:54:39) sasl: DIGEST-MD5 client step 2
(07:54:39) sasl: no server challenge
(07:54:39) connection: Connection error on 03825168 (reason: 3 description: Invalid response from server)
[font="Arial"][color="Blue"]This seems logical to me because the Jabberd server is configured to use [FILE]port 5223[/FILE] for SSL[/color][/font]
```


If Pidgin is configured to require encryption and pointed to port 5223, then yet again the logs reveal that it tried to connect via port 5222:
	
	



```
(08:10:46) proxy: Connecting to archaxis.net:5222 with no proxy
(08:10:46) proxy: Connection in progress
(08:10:46) proxy: Connecting to archaxis.net:5222.
(08:10:46) proxy: Connected to archaxis.net:5222.[font="Arial"][color="Blue"]
. . .fails and issues this complaint:[/color][/font]
(08:10:46) connection: Connection error on 02BB87B8 
(reason: 5 description: You require encryption, but it is not available on this server.)
```

Well, SSL is not available on port 5222 because c2s.xml is configured as follows:

```
<port>5222</port>
    <ssl-port>5223</ssl-port>
    <pemfile>/usr/local/etc/jabberd/.ssh/server.pem</pemfile>
    <verify-mode>7</verify-mode>

    <!-- SSL CA chain. Used to verify client certificates. CA names published to client upon connection -->
    <cachain>/usr/local/etc/jabberd/.ssh/ca_cert.pem</cachain>
```
Apparently, port 5223 is _depreciated_ in some of the lexicon; perhaps I don't understand the nuance here, but it seems practical to me to let unencrypted sessions use port 5222 and reserve 5223 for SSL.  Why call the latter "old style"?


And a final question:  Why does the Jabberd log "No CA chain specified" when indeed, the c2s.xml specifies <cachain>/usr/local/etc/jabberd/.ssh/ca_cert.pem</cachain>  ?

...from the Jabberd debug log:

```
SM  : sx (ssl.c:818) initialising ssl plugin
SM  : sx (ssl.c:911) No CA chain specified. Loading SSL default CA certs: /etc/ssl/certs
SM  : sx (ssl.c:943) setting ssl context '*' verify mode to 00
SM  : sx (ssl.c:964) ssl context '*' initialised; 
certificate and key loaded from /usr/local/etc/jabberd/.ssh/server.pem


S2S : sx (ssl.c:348) using cipher AES256-SHA (256 bits)
S2S : sx (ssl.c:234) external_id: Got peer certificate
S2S : sx (ssl.c:239) external_id: Created id-on-xmppAddr SSL object
S2S : sx (ssl.c:299) external_id: Can't get commonName(5). Possibly malformed cert. Continuing.

C2S : Fri Sep  2 07:16:24 2011 [notice] [0.0.0.0, port=5222] listening for connections
C2S : sx (ssl.c:504) in _sx_ssl_rio
C2S : Fri Sep  2 07:16:24 2011 [notice] [0.0.0.0, [B]port=5223] listening for SSL connections[/B]
```

Perhaps I should abandon all references to port 5223 and reconfigure Jabber to use only port 5222?


----------



## AndyUKG (Sep 2, 2011)

Possibly its using StartTLS, which would mean it would connect to the non-SSL port for both encrypted and unencrypted connections. ie see here: http://en.wikipedia.org/wiki/STARTTLS

Other than that I can't say, I use ejabberd (also from ports) and it works well for me...

Andy.


----------

