From mjt at tls.msk.ru Wed Mar 8 12:46:35 2023 From: mjt at tls.msk.ru (Michael Tokarev) Date: Wed, 8 Mar 2023 14:46:35 +0300 Subject: [gnutls-help] certtool: overriding certain fields of a cert req? Message-ID: <8b5bf448-b259-d2e6-3162-4ea2bea39251@msgid.tls.msk.ru> Hello! Is there a way in certtool to override certain fields in a certificate request when issuing a certificate, such as subject/dn, for example like this can be done with openssl: openssl ca -infiles user.crs -out user.crt -subj "/CN=foo/C=BAR/O=baz" ? I tried to list dn in the template file, but apparently it is being ignored when processing a crq and doing --generate-certificate. Thanks, /mjt From mjt at tls.msk.ru Thu Mar 9 08:37:28 2023 From: mjt at tls.msk.ru (Michael Tokarev) Date: Thu, 9 Mar 2023 10:37:28 +0300 Subject: [gnutls-help] certtool, honor_crq_extensions: The request is invalid? Message-ID: <4f19a5e6-37d7-b65b-e3c7-6bb01605d54d@msgid.tls.msk.ru> Hello! Is there actually a way to keep/honor certificate request extensions? 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. 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. What I'm doing wrong? Thanks, /mjt From mk at cognitivedissonance.ca Sat Mar 18 22:37:05 2023 From: mk at cognitivedissonance.ca (mk) Date: Sat, 18 Mar 2023 17:37:05 -0400 Subject: [gnutls-help] PSK DTLS Message-ID: <65785b7c-4bc9-660e-827a-b394bd243a22@cognitivedissonance.ca> Does anyone know of any (gnuTLS) examples of DTLS using PSK? I am working on a C++ network socket library which wraps gnuTLS (the C API); TLS and DTLS are working client and server side using X.509, and TLS using PSK.? However, DTLS using PSK fails client side during the handshake, after the DTLS cookie is sent, with "A packet with illegal or unsupported version was received". Existing examples in the manual and online have been invaluable to me with the work up to now, but I have been unable to find any for this. From ueno at gnu.org Sun Mar 19 05:11:21 2023 From: ueno at gnu.org (Daiki Ueno) Date: Sun, 19 Mar 2023 13:11:21 +0900 Subject: [gnutls-help] PSK DTLS In-Reply-To: <65785b7c-4bc9-660e-827a-b394bd243a22@cognitivedissonance.ca> (mk@cognitivedissonance.ca's message of "Sat, 18 Mar 2023 17:37:05 -0400") References: <65785b7c-4bc9-660e-827a-b394bd243a22@cognitivedissonance.ca> Message-ID: <877cvdgz2u.fsf-ueno@gnu.org> Hello, mk writes: > Does anyone know of any (gnuTLS) examples of DTLS using PSK? I tried with gnutls-serv and gnutls-cli with the -u option, and encountered a crash caused by an incorrect usage of gnutls_psk_server_get_username in gnutls-cli. After applying a fix for that[1], I got it working as below: psktool -u test -p passwd.psk gnutls-serv -u --pskpasswd=passwd.psk --priority=NORMAL:+ECDHE-PSK:+DHE-PSK:+PSK gnutls-cli localhost -u -p 5556 --priority NORMAL:-VERS-TLS1.3:+ECDHE-PSK:+DHE-PSK:+PSK --pskusername test --pskkey $(sed -n 's/^test:\(.*\)/\1/p' passwd.psk) and it works: - Description: (DTLS1.2-X.509)-(ECDHE-SECP256R1)-(CHACHA20-POLY1305) - Session ID: 43:82:0A:96:74:20:3E:BA:5A:45:59:B8:ED:AA:4D:D7:18:0B:EB:EE:4B:2A:AE:48:1A:46:29:2F:52:33:85:E2 - PSK authentication. PSK hint '' - Options: extended master secret, safe renegotiation, - Handshake was completed > I am working on a C++ network socket library which wraps gnuTLS (the C > API); TLS and DTLS are working client and server side using X.509, and > TLS using PSK.? However, DTLS using PSK fails client side during the > handshake, after the DTLS cookie is sent, with "A packet with illegal > or unsupported version was received". Maybe it might be helpful to look at the diagnostic logs, collected with GNUTLS_DEBUG_LEVEL. > Existing examples in the manual and online have been invaluable to me > with the work up to now, but I have been unable to find any for this. Footnotes: [1] https://gitlab.com/gnutls/gnutls/-/merge_requests/1730 Regards, -- Daiki Ueno From ueno at gnu.org Mon Mar 20 02:47:58 2023 From: ueno at gnu.org (Daiki Ueno) Date: Mon, 20 Mar 2023 10:47:58 +0900 Subject: [gnutls-help] certtool: overriding certain fields of a cert req? In-Reply-To: <8b5bf448-b259-d2e6-3162-4ea2bea39251@msgid.tls.msk.ru> (Michael Tokarev's message of "Wed, 8 Mar 2023 14:46:35 +0300") References: <8b5bf448-b259-d2e6-3162-4ea2bea39251@msgid.tls.msk.ru> Message-ID: <875yaw19dd.fsf-ueno@gnu.org> Hello, Michael Tokarev writes: > Is there a way in certtool to override certain fields in a certificate > request when issuing a certificate, such as subject/dn, for example like > this can be done with openssl: > > openssl ca -infiles user.crs -out user.crt -subj "/CN=foo/C=BAR/O=baz" > > ? > > I tried to list dn in the template file, but apparently it is being > ignored when processing a crq and doing --generate-certificate. Just to confirm: is my understanding correct that you are trying to override DN of an existing certificate request something like the following, right? certtool --generate-certificate --load-request user.crs \ --load-ca-privkey=... --load-ca-certificate=... \ --template=overriding-dn.tmpl As far as I read the certtool code, this doesn't seem to be supported: values from the template are only respected when no certificate requests are given: https://gitlab.com/gnutls/gnutls/-/blob/5005e0825a0dba81ed94bc262e11cc67b1d50beb/src/certtool.c#L365 If there is a specific use-case for this feature, feel free to file a ticket at the issue tracker: https://gitlab.com/gnutls/gnutls/-/issues Regards, -- Daiki Ueno From ueno at gnu.org Mon Mar 20 02:59:36 2023 From: ueno at gnu.org (Daiki Ueno) Date: Mon, 20 Mar 2023 10:59:36 +0900 Subject: [gnutls-help] certtool, honor_crq_extensions: The request is invalid? In-Reply-To: <4f19a5e6-37d7-b65b-e3c7-6bb01605d54d@msgid.tls.msk.ru> (Michael Tokarev's message of "Thu, 9 Mar 2023 10:37:28 +0300") References: <4f19a5e6-37d7-b65b-e3c7-6bb01605d54d@msgid.tls.msk.ru> Message-ID: <871qlk18tz.fsf-ueno@gnu.org> Hello, Michael Tokarev 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 From mjt at tls.msk.ru Mon Mar 20 12:35:24 2023 From: mjt at tls.msk.ru (Michael Tokarev) Date: Mon, 20 Mar 2023 14:35:24 +0300 Subject: [gnutls-help] certtool, honor_crq_extensions: The request is invalid? In-Reply-To: <871qlk18tz.fsf-ueno@gnu.org> References: <4f19a5e6-37d7-b65b-e3c7-6bb01605d54d@msgid.tls.msk.ru> <871qlk18tz.fsf-ueno@gnu.org> Message-ID: 20.03.2023 04:59, Daiki Ueno wrote: ..>> 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? Sure. This comes out of standard windows 10 certreq.exe, with the following description file: --- mjt.inf --- [NewRequest] Subject = "CN=Michael Tokarev,O=JSC CITTS,C=RU" FriendlyName = "Michael Tokarev" KeyUsage = "CERT_DIGITAL_SIGNATURE_KEY_USAGE" HashAlgorithm = SHA256 KeyAlgorithm = RSA KeyLength = 2048 ProviderName = "Microsoft Base Smart Card Crypto Provider" --- end --- with this command: certreq.exe -new mjt.inf mjt.csr This is the contents of mjt.csr which is being produced with the above command: -----BEGIN NEW CERTIFICATE REQUEST----- MIIDizCCAnMCAQAwOzELMAkGA1UEBhMCUlUxEjAQBgNVBAoMCUpTQyBDSVRUUzEY MBYGA1UEAwwPTWljaGFlbCBUb2thcmV2MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAxQ7CtR/pwd4KtRB1pfwqVwgMgHxwetPB4h8WdefXNv2bJMMhIvrQ 4TY+vw0E59y7WWrUlNT5FCFfTWiLgWczjsoB7GtmAR62M8HsTcDXjzfB+g1YxxZ2 R0ceFVPtmOrE4xTjVvdCCRVN1toOB2dqQBW47yGqfXs3I87D9XrJXiHATvwT53sO Ha4CPDUYDT+70lj+mcjKFrrAobLsKdhO3uhi8ou/txruL43hjqzlCvRioYJx9Ftc u78swPFoxH7GhstwULKvAcZYJKS5ZOtBvnyUixZx+o88XL5FTX5IHyHe3SSK305Q TtTP9AwF9kgp4VqaZbVHTBN3L63T4Mvo1wIDAQABoIIBCTAcBgorBgEEAYI3DQID MQ4WDDEwLjAuMTkwNDQuMjA9BgkrBgEEAYI3FRQxMDAuAgEJDA9NQVZFLnRscy5t c2sucnUMC1RMU1xtanQtYWRtDAtjZXJ0cmVxLmV4ZTA+BgkqhkiG9w0BCQ4xMTAv MA4GA1UdDwEB/wQEAwIHgDAdBgNVHQ4EFgQUemj+4owKzTpVSQZh3+dHLId4HhMw agYKKwYBBAGCNw0CAjFcMFoCAQIeUgBNAGkAYwByAG8AcwBvAGYAdAAgAEIAYQBz AGUAIABTAG0AYQByAHQAIABDAGEAcgBkACAAQwByAHkAcAB0AG8AIABQAHIAbwB2 AGkAZABlAHIDAQAwDQYJKoZIhvcNAQELBQADggEBADjd0Tt5VCLSH1Y9GPABuu/+ /fDvAU4SEvdORGKDckIyI6mL6lwP/M7xLbN+MmxeTT5r9Qamwie9cx7WOtv+PdJQ g8PUzqbbJsPMjiwYrljAvSJGtcZ9kOJt4JDqCwMkjoAKke/qEieCpVHASQGu/5Ik NYwVYvXSiePb5tehdrzeiIsGEraamrrodwpr6LabyqSwLARxjmeg3M1i6DoRd1Cd RTCvkROTNpy3vXXU9nlAE1/WIYXCPzhFH/CZAFPH+mToTBM2arSpvhBu+IX67oC0 vipWJ5czR8EdLNtVJN6m+D2028gwBK4Ek9ZLpucv53kXeNrYh+Ou8oSLOqtVR8c= -----END NEW CERTIFICATE REQUEST----- When certtool is used with a template file which have honor_crq_extensions field, it fails with the above command. Thank you! /mjt