#1201 Unable to Download Certificate with Browser
Closed: Fixed None Opened 11 years ago by rcritten.


From Firefox Browser installed on RHEL6.1 IPA server, unable to download the Certificate for Host.

- kinit admin
- firefox&
- Click on Identity->Host-> Add a host-
- Post the CSR and once signed, click on Get to copy and past the Certificate. 
- run the openssl x509 -in file.crt -noout -text

# openssl x509 -in dhcp210-7.crt -noout -text
unable to load certificate
140453227505480:error:0906D064:PEM routines:PEM_read_bio:bad base64

When selecting all from the browser and pasting it on text file, the CR/LF
characters are not there , which makes the file unsable, so the only option is
to run the below command

$ipa host-show dhcp210-7.gsslab.pnq.redhat.com --out dhcp210-7.crt

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.

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.

Metadata Update from @rcritten:
- Issue assigned to jdennis
- Issue set to the milestone: FreeIPA 2.1.4 (bug fixing)

5 years ago

Login to comment on this ticket.