Hello, Michael Tokarev <[email protected]> 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 _______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
