Discussion:
[charms] Incorrect Padding for SSL Cert/Key
James Beedy
2017-01-28 21:04:11 UTC
Permalink
I'm having issues with padding when trying to specify key/cert as config
options for Haproxy, and have experienced the same issue in the past, when
trying to specify key/cert for the Openstack charms. Could someone give an
example of what the correct padding of a base64 encoded ssl cert might look
like in the charm config yaml.

My charm config looks like this -> http://paste.ubuntu.com/23882917/

The error I'm getting is this -> http://paste.ubuntu.com/23882921/

Thanks
James Beedy
2017-01-29 00:00:28 UTC
Permalink
Ok, progress. I've encoded my cert and key to base64 strings and specified
them in my haproxy config, and seem to be getting past the padding error.
My issue now, is that I am not seeing the cert/key in /etc/ssl/private on
the haproxy host once deployed. I'm thinking specifying the ssl cert/key
will work for the Openstack charms now that I've got the encoding part
squared away. Still stumped by haproxy though ... can't seem to get it
provision the cert/key correctly for the life of me. Possibly there is
something else I'm missing here ...
Post by James Beedy
I'm having issues with padding when trying to specify key/cert as config
options for Haproxy, and have experienced the same issue in the past, when
trying to specify key/cert for the Openstack charms. Could someone give an
example of what the correct padding of a base64 encoded ssl cert might look
like in the charm config yaml.
My charm config looks like this -> http://paste.ubuntu.com/23882917/
The error I'm getting is this -> http://paste.ubuntu.com/23882921/
Thanks
Adam Collard
2017-01-30 09:41:30 UTC
Permalink
Post by James Beedy
Ok, progress. I've encoded my cert and key to base64 strings and specified
them in my haproxy config, and seem to be getting past the padding error.
My issue now, is that I am not seeing the cert/key in /etc/ssl/private on
the haproxy host once deployed. I'm thinking specifying the ssl cert/key
will work for the Openstack charms now that I've got the encoding part
squared away. Still stumped by haproxy though ... can't seem to get it
provision the cert/key correctly for the life of me. Possibly there is
something else I'm missing here ...
What version of the charm are you using? What Ubuntu series are you
deploying to?

I suspect you're missing the correct `services` config. There are tests for
the SSL termination feature of the charm in
`tests/12_deploy_{trusty,xenial}.py` perhaps these might shed some light on
the right invocation?
Post by James Beedy
I'm having issues with padding when trying to specify key/cert as config
options for Haproxy, and have experienced the same issue in the past, when
trying to specify key/cert for the Openstack charms. Could someone give an
example of what the correct padding of a base64 encoded ssl cert might look
like in the charm config yaml.
My charm config looks like this -> http://paste.ubuntu.com/23882917/
The error I'm getting is this -> http://paste.ubuntu.com/23882921/
Thanks
--
Juju-dev mailing list
https://lists.ubuntu.com/mailman/listinfo/juju-dev
Pete Vander Giessen
2018-02-16 16:34:21 UTC
Permalink
Hi All,

I came across this thread when troubleshooting a similar problem, and
wanted to drop in the solution we came up with for posterity:

1) If you're dealing with an API, and the API comes back with an "incorrect
padding" error while parsing an SSL Cert, it usually means that the
formatting got munged somewhere. With most of the openstack charms, when
specifying an ssl cert in a bundle, you actually need to embed a yaml
escaped string inside of your yaml escaped string. I looks something like
this:

ssl_cert: |
|
your properly formatted ssl cert goes here.

Note that there are two pipes indicating the beginning of a yaml string in
the above config setup. You need them both! (Double escaping a big text
blob containing special characters is a really common pattern in a lot of
APIs -- you generally want to be aware of it, and watch out for it.)

2) For haproxy, you need to specify a service that listens on port 443 in
the "services" config key. By default, haproxy will only setup a service
listening on port 80. As Adam Collard mentioned, there are some great
examples in the haproxy tests: `tests/12_deploy_{trusty,xenial}.py`

~ PeteVG

Loading...