On 03/06/2012 09:56 PM, Rob Crittenden wrote:
Rob Crittenden wrote:
Jan Cholasta wrote:
Dne 18.1.2012 00:04, Rob Crittenden napsal(a):
Jan Cholasta wrote:
Dne 16.1.2012 22:02, Rob Crittenden napsal(a):
Rob Crittenden wrote:
Jan Cholasta wrote:
Dne 13.1.2012 20:53, Rob Crittenden napsal(a):
When viewing a certificate it will show the serial number as hex

# ipa service-show HTTP/rawhide.example.com
Principal: HTTP/rawhide.example....@example.com
Certificate: [snip]
Keytab: True
Managed by: rawhide.example.com
Subject: CN=rawhide.example.com,O=EXAMPLE.COM
Serial Number: 0x403 (1027)
Issuer: CN=EXAMPLE.COM Certificate Authority
Not Before: Fri Jan 13 15:00:44 2012 UTC
Not After: Thu Jan 13 15:00:44 2022 UTC
Fingerprint (MD5): e5:43:17:0d:8d:af:d6:69:d8:fb:eb:ca:79:fb:47:69
Fingerprint (SHA1):



Displaying a host or a service in the webUI fails with "IPA error
invalid 'serial_number': Decimal or hexadecimal number is required
serial number".

I would suggest to do the nifty formatting of serial numbers on the
client side, that would fix the webUI issue, allow non-IPA
clients to
parse the number without dissecting the string representation of it
probably also save me a hack in the type conversion overhaul. You
for example add a parameter flag like "format_serial_number" to
to the client that it should format the value as a serial number.


Well, we want to do as little client formatting as possible. The
idea is
to have a very thin client.

It doesn't seem right to me to enforce this specific representation of
what is really just an integer at the API level. Doing a little
formatting on the client side won't make the client(s) particularly
will it?

Yes. The current code just outputs labels and data. There is no "if it
is this attribute then do that" logic.

IMHO there is too much stuff done on server that would make more sense
to do on client anyway (especially CLI-specific stuff such as CSV
parsing). What is the reason we want such a thin client?

To avoid double work such that every time we want a formatting
change we
have to change it in multiple places. This lesson was learned in v1.

I believe there should be clear separation of presentation and
but perhaps I'm a little bit too idealistic :-).

You have a point, serial number is defined as an integer. Perhaps we
should revisit this decision to display hex at all.

I'll look into fixing the UI side.

I don't see this error in services, it displays correctly. I'm not
if it is my browser or what but hosts don't display much of anything


I have just checked both master and ipa-2-2 and I'm getting the same
error message (tested in Firefox 9.0.1) when viewing details of a host
or a service with the usercertificate attribute set.

BTW, wouldn't it make sense to format serial numbers in the cert
in the same way?

Perhaps. Like I said, I'm not really in favor of this change.


Maybe we can do a compromise of some sort. What about allowing the
client to specify with each request what representation/formatting the
server should use for the resulting entries and attributes?

That would be mighty flexible but would open a new can of worms. I think
long term I'd like to be able to request what attributes to see (ala
ldapsearch) but that too is a bit out of scope.

This comes down to Output being rather loosely defined and we already
have a ticket open on that. It basically just defines the broad types of
data to be returned (string, list, dict, etc) but not the internal
components of complex types.

Took a new approach and created a new output attribute,
serial_number_hex, that is displayed separately.

UI portion added as well.

ACK for the UI part. I attached a patch which extends UI static testing data - to keep things in solid state.

I think this approach is still evil (as the whole ticket) but I don't have a better solution (in CLI).

Isn't the '0x' part a bit redundant? The label already says '(hex)'. However I can buy a 'It is a convention.' argument.

Petr Vobornik
From 6302b8074bdc9fa1b46d3d848fb0e81460db4ba4 Mon Sep 17 00:00:00 2001
From: Petr Vobornik <pvobo...@redhat.com>
Date: Wed, 7 Mar 2012 16:32:45 +0100
Subject: [PATCH] Certificate serial number in hex format - ui testing data

Updated UI static content to contain value and label for certificate serial_number_hex.

 install/ui/test/data/ipa_init.json     |    1 +
 install/ui/test/data/service_show.json |    1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/install/ui/test/data/ipa_init.json b/install/ui/test/data/ipa_init.json
index 0182aab733a5541d3149ea582bd975faf04db10a..df9fbe9c839b696c2dfc95d85faf8f94e93f08f1 100644
--- a/install/ui/test/data/ipa_init.json
+++ b/install/ui/test/data/ipa_init.json
@@ -177,6 +177,7 @@
                             "revoke_confirmation": "To confirm your intention to revoke this certificate, select a reason from the pull-down list, and click the \"Revoke\" button.",
                             "revoked": "Certificate Revoked",
                             "serial_number": "Serial Number",
+                            "serial_number_hex": "Serial Number (hex)",
                             "sha1_fingerprint": "SHA1 Fingerprint",
                             "superseded": "Superseded",
                             "unspecified": "Unspecified",
diff --git a/install/ui/test/data/service_show.json b/install/ui/test/data/service_show.json
index 0595828bea2e84845b2448357757b4927feba1eb..37b85df8d61f89a2d46d7a3e358f1957a941fb49 100644
--- a/install/ui/test/data/service_show.json
+++ b/install/ui/test/data/service_show.json
@@ -49,6 +49,7 @@
             "md5_fingerprint": "08:86:a9:f9:87:af:0d:d7:42:01:e0:5f:12:9b:32:7f",
             "serial_number": "1",
+            "serial_number_hex": "0x1",
             "sha1_fingerprint": "b8:4c:4b:79:4f:13:03:79:47:08:fa:6b:52:63:3d:f9:15:8e:7e:dc",
             "subject": "CN=dev.example.com,O=EXAMPLE.COM",
             "usercertificate": [

Freeipa-devel mailing list

Reply via email to