[gnutls-help] certtool, honor_crq_extensions: The request is invalid?

[Daiki Ueno]

Hello,

Michael Tokarev <mjt at tls.msk.ru> writes:

> Doing a simple certreq.exe -new to generate a crq, and certtool either complains
> or does not do what I think it should.  For example, this crq:
>
> PKCS #10 Certificate Request Information:
> 	Version: 1
> 	Subject: CN=Michael Tokarev,O=AO «CITTS»,C=RU
> 	Subject Public Key Algorithm: RS
> 	Algorithm Security Level: Medium (2048 bits)
> 		Modulus (bits 2048):
> 			...
> 		Exponent (bits 24):
> 			01:00:01
> 	Signature Algorithm: RSA-SHA256
> 	Attributes:
> 		Unknown attribute 1.3.6.1.4.1.311.13.2.3:
> 			ASCII: ..10.0.19044.2
> 			Hexdump: 160c31302e302e31393034342e32
> 		Unknown attribute 1.3.6.1.4.1.311.21.20:
> 			ASCII: 0......MAVE.tls.msk.ru..TLS\mjt-adm..certreq.exe
> 			Hexdump: 302e0201090c0f4d4156452e746c732e6d736b2e72750c0b544c535c6d6a742d61646d0c0b636572747265712e657865
> 		Extensions:
> 			Key Usage (critical):
> 				Digital signature.
> 			Subject Key Identifier (not critical):
> 			029469c015457c9af37c3f71b0ba351eb44aec8a
> 		Unknown attribute 1.3.6.1.4.1.311.13.2.2:
> 			ASCII: 0Z....R.M.i.c.r.o.s.o.f.t. .B.a.s.e. .S.m.a.r.t. .C.a.r.d. .C.r.y.p.t.o. .P.r.o.v.i.d.e.r...
> 			Hexdump:
> 			305a0201021e52004d006900630072006f0073006f006600740020004200610073006500200053006d00610072007400200043006100720064002000430072007900700074006f002000500072006f00760069006400650072030100
> Other Information:
> 	Public Key ID:
> 		sha1:595498a26031d1dca7a5c761ad75bb7b663282ca
> 		sha256:c6153153234e0a490e0110df3f9d21fe3a421cfa920d9ceb32fa3ff41ddcbdb5
> 	Public Key PIN:
> 		pin-sha256:xhUxUyNOCkkOARDfP50h/jpCHPqSDZzrMvo/9B3cvbU=
> Self signature: verified
>
>
> Here's what's happening:
>
> certtool -V -d10 --generate-certificate --load-request mjt.crq --template /dev/stdin <<- EOF
>         expiration_days = 365
>         signing_key
>         honor_crq_extensions
>         #honor_crq_ext = 2.5.29.17
>         #honor_crq_ext = 1.3.6.1
>         #.4.1.311.13.2.2
> EOF
>
> Setting log level to 10
> Generating a signed certificate...
> |<3>| ASSERT: ../../../lib/x509/common.c[_gnutls_strdatum_to_buf]:1543
> |<3>| ASSERT: ../../../lib/x509/common.c[_gnutls_strdatum_to_buf]:1543
> |<3>| ASSERT: ../../../lib/x509/common.c[_gnutls_copy_data]:1610
> |<3>| ASSERT: ../../../lib/x509/common.c[_gnutls_strdatum_to_buf]:1543
> |<3>| ASSERT: ../../../lib/x509/common.c[_gnutls_strdatum_to_buf]:1543
> |<3>| ASSERT: ../../../lib/x509/common.c[_gnutls_strdatum_to_buf]:1543
> |<3>| ASSERT: ../../../lib/x509/common.c[_gnutls_copy_data]:1610
> |<3>| ASSERT: ../../../lib/x509/common.c[_gnutls_strdatum_to_buf]:1543
> |<3>| ASSERT: ../../../lib/x509/common.c[_gnutls_strdatum_to_buf]:1543
> |<3>| ASSERT: ../../../lib/nettle/mpi.c[wrap_nettle_mpi_print]:60
> |<3>| ASSERT: ../../../lib/nettle/mpi.c[wrap_nettle_mpi_print]:60
> |<3>| ASSERT:
> | ../../../lib/x509/x509_write.c[gnutls_x509_crt_set_subject_key_id]:1609
> set_subject_key_id: The request is invalid.

Assuming this is with GnuTLS 3.7.9 (or a similar version), the last line
means that there was some failure when retrieving a subjectKeyIdentifier
extension from the certificate, where the extension exists but cannot be
retrieved for some reason.

Would it be possible to share the certificate request so I can reproduce
it locally?

> This will always be this way until I remove (comment-out) honor_crq_extensions.
> But later, even when I uncomment other honor_crq_ext= (I tried random ones which
> seems to be present, in this crq or in other crqs), the resulting exts are not
> shown in the generated certificate no matter how I specify them.

The usage of the honor_crq_extensions looks correct to me.

Regards,
-- 
Daiki Ueno