Re: Starting tracker gives [('SSL routines', '', 'PEM lib')]

"John P. Rouillard" <[email protected]>
Newsgroups gmane.comp.bug-tracking.roundup.user
Message-ID <[email protected]>
Hi Ed:

Just want to verify your environment:

Python3
Roundup version 2.1 .0

Is this correct?

In message <PH7PR12MB565668724368AA35101C703B84889@PH7PR12MB5656.namprd12.prod.
outlook.com>,
Ed Trumbull writes:
>Still working my way through setting up my tracker, I have gotten to
>the point where it started, and I added our pem file and specified
>its path in the roundup-server initialization file. Now, when I start
>the tracker, it abends and all I see in the log file is "[('SSL
>routines', '', 'PEM lib')]"

Well that's not a helpful error.

>As usual, I suspect I'm missing something straightforward, but don't
>know what...

I was going to say:

    Possibly not. Most Roundup installs use a real web server (apache,
    nginx, hiawatha etc.) as a front end to handle SSL/TLS. Then the
    front end proxies to roundup-server or a wsgi server like gunicorn
    running without SSL. This allows people to incorporate roundup in
    their existing web sites. So AFAIK that SSL code hasn't gotten
    much use and isn't covered by CI. It's also code I haven't worked
    with.

When developing a test sequence for you to run using my roundup
instances, I ended up getting a traceback (abend) using just the -s
flag with auto cert creation. So while the SSL connection was correct,
the back end server didn't serve up web pages. That led me to:

   https://issues.roundup-tracker.org/issue2551137

that I filed over a year ago. It looks like there were core code
changes since the SSL support was added in 2007 that caused it to
break.

Since it looks like there will still be issues even if we fix the PEM
problem, my suggestion would be to run an actual web server. Have the
web server proxy to roundup-server/gnuiconr/uwsgi or run roundup. If
Roundup is going to be made internet facing, running a real web server
that can implement DOS protection, connection throttling etc. is kind
of required.

That said I would like to at least open a ticket on your PEM issue.
Can you tell me how you created your PEM file? Also I think the file
has to have both the key and the cert in it. So the file should have:

-----BEGIN PRIVATE KEY-----
stuff inside is a PKCS#8 key
-----END PRIVATE KEY-----

-----BEGIN CERTIFICATE-----
different stuff
-----END CERTIFICATE-----

at the very least. There may be more certs (in the certificate chain)
added to the file. Also you should be able to verify it with:

  openssl x509 -in file.pem -text

and see a printed copy of the cert. Similarly for the private key,

  openssl rsa -inform PEM -in file.in -text 

which decodes the PKCS#8 front matter and generates a corresponding
PKCS#1 format RSA private key.

I just tried 'roundup_server -s -e file.pem ...' with a PEM file I
have signed by Let's Encrypt. roundup-server started and ran. I was
able to use:

  openssl s_client -connect <host>:<port>

to create an SSL connection to it and verify the subject and issuer
were correct.

So my suspicion in that your PEM file isn't correct. If I have just
the public key in the PEM file, using it results in roundup-server
exiting with:

  [('PEM routines', 'get_name', 'no start line'),
   ('SSL routines', 'SSL_CTX_use_certificate_file', 'PEM lib')]

Which looks similar to your error and kind of supports my guess about
the PEM file. If you can confirm that you are missing the key or cert
or something, I'll add some comments to that key in the config file.

Thanks.
 
--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
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.