0.24 not serving puppet provided certificate

Discussion:

Chris Phillips

2011-05-26 10:17:27 UTC

Hi,

I've rolled out an environment where func is using the puppet certs. I have
a handful of old el4 boxes and *thought* func was OK on them until I came to
use than and found that 0.24 doesn't support the puppet certs, and the
chances of upgrading the whole chaining of dependencies (including python
2.3 -> 2.4) is just a no go.

So instead I commented out the attempt to hit certmaster, which
is obviously not being used, and sylinked the puppet certs to the normal
func locations. After doing this, the func daemon does start and listen, but
doesn't actually do anything with no sign of server side errors with DEBUG
enabled in the log.

It seems that it just doesn't serve the cert at all. Using openssl -s_client
on it, I just get:

openssl s_client -connect hostname:51234
CONNECTED(00000003)
140144621885256:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:674:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 113 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

ANyone have any ideas about any way to nudge func into life with these
alternative certs? I suppose it has to be some attribute of the certificate
as created by openssl libraries on an el6 server, being used on an el4
client, but I've not a clue what, and would doubt it's possible to change
the attributes of the certs.

Thanks

Chris

Chris Phillips

2011-05-26 10:42:55 UTC

Permalink

Hi,

As is the way, I made *some* progress after posting. Func was expecting a
short hostname, but puppet created fqdn certs, so I sorted that, and it's
now hopefully got the certificate it wants (it is at least loading the
appropriately named pem and cert files... however still nothing, with
s_client, I'm now seeing something on the server side:

[...]
self.raw_requestline = self.rfile.readline()
File "/usr/lib/python2.3/socket.py", line 338, in readline
data = self._sock.recv(self._rbufsize)
File "/usr/lib/python2.3/site-packages/certmaster/SSLConnection.py", line
150, in recv
raise e
Error: [('SSL routines', 'SSL3_GET_CLIENT_HELLO', 'length mismatch')]

with the openssl client agreeing on something:

CONNECTED(00000003)

Post by Chris Phillips

TLS 1.0 Handshake [length 006c], ClientHello

01 00 00 68 03 01 4d de 2c f3 4b de 48 cf 75 08
1e b2 2c 42 57 ee ad b6 39 cc 0e 40 bb 02 ce a9
81 fa 06 0a 5f bd 00 00 3a 00 39 00 38 00 88 00
87 00 35 00 84 00 16 00 13 00 0a 00 33 00 32 00
9a 00 99 00 45 00 44 00 2f 00 96 00 41 00 05 00
04 00 15 00 12 00 09 00 14 00 11 00 08 00 06 00
03 00 ff 02 01 00 00 04 00 23 00 00
<<< SSL 3.0 Alert [length 0002], fatal handshake_failure
02 28
140325371447112:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:674:
---

Thanks

Chris

Post by Chris Phillips
Hi,
I've rolled out an environment where func is using the puppet certs. I have
a handful of old el4 boxes and *thought* func was OK on them until I came to
use than and found that 0.24 doesn't support the puppet certs, and the
chances of upgrading the whole chaining of dependencies (including python
2.3 -> 2.4) is just a no go.
So instead I commented out the attempt to hit certmaster, which
is obviously not being used, and sylinked the puppet certs to the normal
func locations. After doing this, the func daemon does start and listen, but
doesn't actually do anything with no sign of server side errors with DEBUG
enabled in the log.
It seems that it just doesn't serve the cert at all. Using openssl
openssl s_client -connect hostname:51234
CONNECTED(00000003)
140144621885256:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 113 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
ANyone have any ideas about any way to nudge func into life with these
alternative certs? I suppose it has to be some attribute of the certificate
as created by openssl libraries on an el6 server, being used on an el4
client, but I've not a clue what, and would doubt it's possible to change
the attributes of the certs.
Thanks
Chris

Chris Phillips

2011-05-26 11:07:57 UTC

Permalink

Hi,

OK, so the s_client was misleading, TLS vs SSLv3... with SSLv3 on both sides
it does work for s_client, however func still isn't happy, which func
saying:

{'hostname.domain.local': ['REMOTE_ERROR',
'xmlrpclib.Fault',
'<Fault 1:
"OpenSSL.crypto.Error:[(\'asn1 encoding routines\', \'ASN1_mbstring_copy\',
\'unknown format\')]">',
' File
"/usr/lib/python2.6/site-packages/func/overlord/client.py", line 881, in
process_server\n retval = getattr(conn, meth)(*args[:])\n File
"/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__\n return
self.__send(self.__name, args)\n File "/usr/lib64/python2.6/xmlrpclib.py",
line 1489, in __request\n verbose=self.__verbose\n File
"/usr/lib64/python2.6/xmlrpclib.py", line 1253, in request\n return
self._parse_response(h.getfile(), sock)\n File
"/usr/lib64/python2.6/xmlrpclib.py", line 1392, in _parse_response\n
return u.close()\n File "/usr/lib64/python2.6/xmlrpclib.py", line 838, in
close\n raise Fault(**self._stack[0])\n']}

Which was actually the error I've always been having form func. With tcpdump
I think I see the handshake complete and a k or so of application data (or
would that be the cert going over?) This unknown format error maybe
apparently be something about hostname verification? Any pointers
appreciated.

Thanks

Chris