[openstack-dev] [Neutron] Representing PEM Format file as string

John Dennis jdennis at redhat.com
Mon Jan 27 14:00:19 UTC 2014


On 01/26/2014 05:36 PM, Rajesh_Mohan3 at Dell.com wrote:
> I am working on SSL VPN BP.
> 
> CA certificate is one of the resources. We decided to use PEM formatted certificates. It is multi-line string 
> 
>   1 -----BEGIN CERTIFICATE-----
>   2 MIID3TCCA0agAwIBAgIJAKRWnul3NJnrMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYD
>  <snip>
>  21 0vO728pEcn6QtOpU7ZjEv8JLKRHwyq8kwd8gKMflWZRng4R2dj3cdd24oYJxn5HW
>  22 atXnq+N9H9dFgMfw5NNefwJrZ3zAE6mu0bAIoXVsKT2S
>  23 -----END CERTIFICATE-----
> 
> Is there a standard way to represent this as single line string? Maybe there is some other project that passes certificates on command line/url. 
> 
> I am looking for some accepted way to represent PEM formatted file on command line. 
> 
> I am thinking of concatenating all lines into single string and rebuilding the file when configuration file is generated.Will we hit any CLI size limitations if we pass long strings.

In general PEM formatted certificates and other X509 binary data objects
should be exchanged in the original PEM format for interoperabilty
purposes. For command line tools it's best to pass PEM objects via a
filename.

However, having said that there is at least one place in Openstack which
passes PEM data via a HTTP header and/or URL, it's the Keystone token id
which is a binary CMS object normally exchanged in PEM format. Keystone
strips the PEM header and footer, strips line endings and modifies one
of the base64 alphabet characters which was incompatible with HTTP and
URL encoding. However what keystone was doing was not correct and in
fact did not follow an existing RFC (e.g. URL safe base64).

I fixed these problems and in the process wrote two small Python modules
base64utils and pemutils to do PEM transformations correctly (plus
general utilities for working with base64 and PEM data). These were
submitted to both keystone and oslo, Oslo on the assumption they should
be general purpose utilities available to all of openstack. I believe
these have languished in review purgatory, because I was pulled off to
work on other issues I haven't had the time to babysit the review.


-- 
John



More information about the OpenStack-dev mailing list