Re: Invalid certificate error

Jonathan Byrne <[email protected]>
Newsgroups gmane.network.up2date.current.devel
Message-ID <[email protected]>
Hunter Matthews ([email protected]) wrote:

> Its still a self signed certificate, BUT did you put a new RHNS-CA-CERT 
> file in /usr/share/rhn? 

Yes, as per the instructions in encryption.txt:

cat cert.txt stunnel.crt > RHNS-CA-CERT

I put that in /usr/share/rhn after making a backup
of the existing one.


> Although the fact that you get an error from stunnel is suspect.
> 
> How did you generate the pem file that you are feeding to stunnel?

As per the instructions in encryption.txt, but I found a couple
of problems with it, one being that steps 3 and 4 are out
of order in the instructions for creating the certificate
(I'm sure you've already noticed that too - stunnel.pem
has to be created first, then cert.txt is generated from it).

The other comes from the stunnel manpage:

The order of contents of the .pem file is also important. It should
contain the unencrypted private key first, then a signed certificate
(not certificate request). There should be also empty lines after
certificate and private key. Plaintext certificate information appended
on the top of generated certificate should be discarded. So the file
should look like this:

-----BEGIN RSA PRIVATE KEY-----
[encoded key]
-----END RSA PRIVATE KEY-----
[empty line]
-----BEGIN CERTIFICATE-----
[encoded certificate]
-----END CERTIFICATE-----
[empty line]

According to that, the private key must come first in stunnel.pem,
followed by the certificate, and  blank lines must separate the key
and the certificate, as well as follow the certificate.

When I generated stunnel.pem file conforming to this, the
error from up2date changed to: Method Not Found.

Logging and debug output now shows:

From stunnel
------------
Nov 29 17:57:31 yamame stunnel[26788]: 8000 opened with TLSv1, cipher DES-CBC3-SHA (168 bits)
Nov 29 17:57:31 yamame stunnel[26788]: SSL_read (socket): Connection reset by peer (104)
Nov 29 17:57:32 yamame stunnel[26788]: Connection reset: 411 bytes sent to SSL, 2345 bytes sent to socket
Nov 29 17:57:51 yamame stunnel[26790]: 8000 connected from 203.216.0.50:46180
Nov 29 17:57:52 yamame stunnel[26790]: 8000 opened with TLSv1, cipher DES-CBC3-SHA (168 bits)
Nov 29 17:57:52 yamame stunnel[26790]: Connection closed: 411 bytes sent to SSL, 2345 bytes sent to socket


From current
------------
standalone.do_POST()
client_address ('127.0.0.1', 46166)
command POST
path https://yamame.gol.ad.jp/XMLRPC
headers Host: yamame.gol.ad.jp
User-Agent: xmlrpclib.py/$Revision: 1.41 $
Content-Type: text/xml
X-Client-Version: 1
Content-Length: 2103
X-Info: XML-RPC Processor (C) Red Hat, Inc ($Revision: 1.30 $)

Requesting: up2date.login
module = up2date
function = login
api = ['header', 'listall_size', 'package', 'source_package_by_name', 'solvedep']
RESPONSE is a Fault
requesthandler.log_request() "POST https://yamame.gol.ad.jp/XMLRPC HTTP/1.0" 200 -


From up2date log
----------------
[Thu Nov 29 17:57:51 2001] up2date updating login info
[Thu Nov 29 17:57:51 2001] up2date Opening rpmdb in /var/lib/rpm/ with option 0
[Thu Nov 29 17:57:51 2001] up2date logging into up2date server


This looks like progress, since it appears that with the 
new .pem made in accordance with the man page, it is 
successfully opening the connection, but then cannot
go further because that's as far as the code goes with
2.7 clients right now?

If so, then using a 2.5 client should work, right?
I can install one and try it, if so.

I'm pretty interested in this project, so whenever you
have a new snapshot ready, I'll be happy to try it out and
see how the 2.7.x stuff goes.

I'm not a programmer, but will be happy to contribute
proofreading and suggestions to the docs where I can.

Cheers,

Jonathan
-- 
Jonathan Byrne, CCNA 		Network Engineer
Global Online Japan		A Division of Exodus Communications K.K.
Tel/fax				+81 3-4354-0293 / +81 3-4354-0171
Email				[email protected]
http://www.gol.com/		http://www.exodus.co.jp/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.