using heimdal x509 functions for certificate handling rather than gnutls

Love Hörnquist Åstrand lha at
Wed Aug 11 11:39:28 MDT 2010

> First thanks for your positive reaction !
>>> Hi Love and Andrew,
>>> On 10/08/2010 11:02, Love Hörnquist Åstrand wrote:
>>>> Dont let me stop you from committing fixes and extensions, it might go faster to get then integrated in
>>>> Mainstream Heimdal if we discuss the changes first though.
>>>> That said, I prefer working code instead of no code.
>>> Ok I have some patches in my repo I'll pushed them to my public repo in the
>>> backupkey_heimdal  (;a=shortlog;h=refs/heads/backupkey_heimdal)
>>> It's the last 5 patches, you'll see some stuff that we already talked about (utf-16 strings, hx509_err and makeproto ...).
>> For the subjectUniqueID and issuerUniqueID I just made the addition of
>> int
>> hx509_ca_tbs_set_unique(hx509_context context,
>> 			hx509_ca_tbs tbs,
>> 			const heim_bit_string *subjectUniqueID,
>> 			const heim_bit_string *issuerUniqueID);
>> which should help you generate the certificate with the extensions.
> I'm ok I was lacking imagination on how to do it ! I'll change my test client as soon as I fetch your change
>> There should be a hx509_cert_get_unique() that matches it for fetching.
> It's ok, will it return the same unique for issuer and subject ?

I ended up creating 

int hx509_cert_get_issuer_unique_id(hx509_context context, hx509_cert p, heim_bit_string *issuer)
int hx509_cert_get_subject_unique_id(hx509_context context, hx509_cert p, heim_bit_string *subject)

so they are split.

>> The api is different then what you proposed, but its because I don't want to keep adding more arguments to hx509_ca_sign() for every extension that get created (hx509_ca_sign_full_now_with_pink_flowers()).
> :-D
>>> For the moment it's raw patches that were make the hiemdalcrt demo program work.
>>> This program tests the following stuff that I'll need to implement the backupkey remote protocol:
>>> * generation of a certificate with a subject unique Id and its private key
>> what format do you have the private key in (or do you need to generate a private key ?)
>> in that format do you expect the private key to exported in ?
> So the private key is a couple of blobs described page 27 (section 2.2.5) of ms-bkrp.pdf:
> Public_Exponent (4 bytes)
> Modulus (256 bytes)
> Prime1 (128 bytes)
> Prime2 (128 bytes)
> Exponent1 (128 bytes)
> Exponent2 (128 bytes)
> Coefficient (128 bytes)
> Private_Exponent (256 bytes)
> My idea (but I didn't tried it much) was to create a RSA object and set the different fields of it with the values extracted from the AD object
> then I'll need a little magic to make a hx509_private_key object.

Yeah, that will work, let me know if you want any help adding this code, if you provide sample blob, I can create a parser that creates the _hx509_private_key for you.

>>> * querying a cert for it's info and among them the subject unique id
>> yet to be created hx509_cert_get_unique().
>>> * converting a DER certificate to an heimdal cert object
>> use hx509_cert_init_data()
>>> * exporting a heimdal cert object to a DER byte string
>> hx509_cert_binary()
>>> I'll need one thing: create a private with just the raw information (exponent, modulus, prime 1, prime 2, exponent 1, exponent 2, coefficient, private exponent) as it's provided and stored by microsoft in the active directory.
>> In what format is the private key provided ? It might be so that there are already a parser for that private key format.
> See above.
> If you had a look on the test program you'll see that I use quite a lot of _hx509 functions

ok, I'll try to have a look at it.

they are private because I don't even want to pretend that I want to support the api, happy to change that though for many of them.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3815 bytes
Desc: not available
URL: <>

More information about the samba-technical mailing list