ssl endpoint parser could report trivial format errors in certificate data more clearly

	@exarkun reported
Trac ID	trac#9173
Type	enhancement
Created	2017-06-11 00:07:34Z

When there is a minor mistake (so minor one might even argue it's no mistake at all) in the formatting of a certificate pem file used with the ssl string endpoint description parser, the reported error ranges from obscure to obtuse. On one system, I get this:

$ twistd -n web -p ssl:9999:certKey=/tmp/cert.pem:privateKey=/tmp/key.pem:extraCertChain=/tmp/chain.pem
Traceback (most recent call last):
  File "bin/twistd", line 11, in <module>
    sys.exit(run())
.
.
.
  File "/home/exarkun/.local/lib/python2.7/site-packages/twisted/internet/_sslverify.py", line 843, in load
    return Class(crypto.load_privatekey(format, data))
  File "/home/exarkun/.local/lib/python2.7/site-packages/OpenSSL/crypto.py", line 2618, in load_privatekey
    _raise_current_error()
  File "/home/exarkun/.local/lib/python2.7/site-packages/OpenSSL/_util.py", line 54, in exception_from_error_queue
    raise exception_type(errors)
OpenSSL.crypto.Error: [('PEM routines', 'PEM_read_bio', 'bad end line')]

On another, the exception at the end of the traceback is this, instead:

OpenSSL.crypto.Error: []

The formatting error that provokes this behavior is to have no trailing newline in cert.pem. If a trailing newline is required, this should be spelled out clearly in the error. But clearly the better solution would be to have this arbitrary and surprising requirement (amusingly, no trailing newline is required on the key pem file).

trac-id__9173 9173
type__enhancement enhancement
reporter__exarkun exarkun
priority__normal normal
milestone__None None
branch__ 
branch_author__ 
status__new new
resolution__None None
component__core core
keywords__None None
time__1497139654516914 1497139654516914
changetime__1497139654516914 1497139654516914
version__None None
owner__None None

Start by reproducing the ssl string endpoint parser failure with the twistd command and certificate files described in the issue, especially a cert.pem without a trailing newline. Locate the parser and its existing tests, then make the resulting certificate-format problem clear or remove the unnecessary formatting requirement; done means the case no longer produces an obscure OpenSSL error.