This may be a candidate for 2.2.

We rely on the LDAP data type to know what kind of data to return to the client. In this case a certificate is considered binary, so we return it that way but know enough to base64 encode it when displaying to the end-user. What we don't have are per-parameter handlers for formatting data on the client side.

So even if on the server I properly create a PEM file it will still show as a giant base64-encoded blob to the end-user (in fact, it will be a base64-encoded base64-encoded certificate!).

Putting it into a 2.1 bucket for now.

This has a client side UI component.

Moving to 2.1.4 now to clear the deck for 2.1.3.

patch
0051-Ticket-1201-Unable-to-Download-Certificate-with-Brow.patch

Submitted as patch: [PATCH 51/51] Ticket 1201 - Unable to Download Certificate with Browser
Also attached.

Certificates are passed through the IPA XML-RPC and JSON as binary
data in DER X509 format. Queries peformed against the LDAP server
also return binary DER X509 format. In all cases the binary DER
data is base-64 encoded.

PEM is standard text format for certificates. It also uses base64 to
encode the binary DER data, but had specific formatting
requirements. The base64 data must be wrapped inside PEM delimiters
and the base64 data must be line wrapped at 64 characters.

Most external software which accepts certificates as input will only
accept DER or PEM format (e.g. openssl & NSS). Although base64 is
closely related to PEM it is not PEM unless the PEM delimters are
present and the base64 data is line wrapped at 64 characters.

We already convert binary DER certificates which have been passed as
base64 in other parts of the IPA code. However this conversion has not
been available in the web UI. When the web UI presented certificates
it did so by filling a dialog box with a single line of base64 data. A
user could not copy this data and use it as input to openssl or NSS
for example.

We resolve this problem by introducing new javascript functions in
certificate.js. IPA.cert.pem_cert_format(text) will examine the text
input and if it's already in PEM format just return it unmodified,
otherwise it will line wrap the base64 data and add the PEM
delimiters. Thus it is safe to call on either a previously formated
PEM cert or a binary DER cert encoded as base64. This applies to
pem_csr_format() as well for CSR's.

Because pem_cert_format() is safe to call on either format the web UI
will see the use of the flag add_pem_delimiters was eliminated except
in the one case where the IPA.cert.download_dialog() was being abused
to display PKCS12 binary data (pkcs12 is neither a cert nor a cert
request). Because of the abuse of the cert.download_dialog() for
pkcs12 it was necessary to retain the flag which in effect said "do
not treat the data as PEM".

Modify the CSR (Certificate Signing Request) dialog box to accept a
PEM formatted CSR. Remove the artifical PEM delimiters above and below
the dialog box which were used to suggest the input needed to be sans
the delimiters. The dialog box continues to accept bare base64 thus
allowing either text format.

Also note this solves the display of certificate data in the UI
without touching anything existing code in the server or command line,
thus it's isolated.

master: 9a039ac

ipa-2-1: 9b7639a