How to request ocsp-must-staple on certificates about uacme HOT 11 CLOSED

With GnuTLS 3.5.8 or later it should be easy to add the necessary feature to the certificate request (look at the csr_gen function, in the crypto.c file)

gnutls_x509_tlsfeatures_t f;
gnutls_x509_tlsfeatures_init(&f);
gnutls_x509_tlsfeatures_add(f, 5);
gnutls_x509_crq_set_tlsfeatures(crq, f);
gnutls_x509_tlsfeatures_deinit(f);

from uacme.

Hi,
I, fortunately, decided to use mbedTLS because I did not want to deal with dependency hell of GnuTLS on FreeBSD 12/clang. While static build mbedTLS has no depends, these are the dependencies of FreeBSD distro GnuTLS-3.6.8:
trousers: 0.3.14_2
tpm-emulator: 0.7.4_2
gmp: 6.1.2_1
p11-kit: 0.23.16.1
libtasn1: 4.13_1
libffi: 3.2.1_3
nettle: 3.4.1_1
Can you please point me to equivalent routines in mbedTLS? I understand it may not be possible because of this and this unresolved requests but I am not conversant with these APIs.

from uacme.

Hi,
I spoke before I found this. I can use pointers to incorporate it into my uacme build.

from uacme.

Please, check if this patch (for mbedTLS only) works for you and let me know. If it does I will consider adding implementations for GnuTLS and OpenSSL.
must-staple-patch.txt

from uacme.

It works!
Yes, I successfully created and compared a certificate on the staging server to that for letsencrypt I noticed one difference in certificate key usage. LE's certificate shows a0 (Digital Signature, Key Encipherment) but the certificate created from uacme used 80 (Digital signatures). I am clueless about certs and I don't know if this is material but I thought I should bring it to your attention.

from uacme.

I noticed one difference in certificate key usage. LE's certificate shows a0 (Digital Signature, Key Encipherment) but the certificate created from uacme used 80 (Digital signatures).

This is the default key usage for a certificate request made by mbedTLS. The patch attached here makes key usage same as GnuTLS. Please let me know if it works.
gnutls_key_usage_patch.txt

from uacme.

Yes, it works.
Please see attached images.
Thank you for these quick fixes.

from uacme.

Something is still missing. While Key encipherment is enabled for RSA certificates, this is not the case with ecc certificates. Please see attached images. The only command line difference when creating the certificates was the type parameter --type RCS vs --type EC.

uacme was built with gcc7 using mbedssl-2.16-2 on solaris.

So, I kept digging, and found [this] (https://mailarchive.ietf.org/arch/msg/tls/iXrlfOACsciKdZNcqz9JKDVr_HU). Does mean we can ignore this bit? Sorry, I have not been able to find a public site using ecc signature to compare against.
Thank you.

from uacme.

The key encipherment key usage bit doesn't make sense in the context of an EC key. As an example see this discussion: https://bugzilla.mozilla.org/show_bug.cgi?id=1560234

There is work underway (but not yet finalized) in the IETF to clarify this point w.r.t RFC 5480: https://datatracker.ietf.org/doc/draft-turner-5480-ku-clarifications/ by updating the text to say this explicitly:

3.  Updates to Section 3

   If the keyUsage extension is present in a certificate that indicates
   id-ecPublicKey as algorithm of AlgorithmIdentifier [RFC2986] in
   SubjectPublicKeyInfo, then following values MUST NOT be present:

     keyEncipherment; and
     dataEncipherment.

   If the keyUsage extension is present in a certificate that indicates
   id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following
   values also MUST NOT be present:

     keyEncipherment; and
     dataEncipherment.

from uacme.

I have not been able to find a public site using ecc signature to compare against.

facebook.com and cloudflare.com have EC certs, and both only have the DigitalSignature bit. Note the lack of keyAgreement bit, which is dangerous: https://www.usenix.org/system/files/conference/woot15/woot15-paper-hlauschek.pdf

from uacme.

Got it. Thanks.

from uacme.