From cloos at jhcloos.com Thu Nov 3 21:43:55 2016 From: cloos at jhcloos.com (James Cloos) Date: Thu, 03 Nov 2016 16:43:55 -0400 Subject: [gnutls-help] Forcing chacha20-poly1305 Message-ID: I've tried quite a few priority strings to force chacha20-poly1305. It seems like it should be easier than: SECURE256:+CHACHA20-POLY1305:-CAMELLIA-256-CBC:-CAMELLIA-256-GCM:-AES-256-CBC:-AES-256-GCM:-AES-256-CCM First, CHACHA20-POLY1305 ought to be part of SECURE256. But given that, is there any way to shorten that string? -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nmav at gnutls.org Fri Nov 4 08:13:19 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 04 Nov 2016 08:13:19 +0100 Subject: [gnutls-help] gnutls 2.12.24 Message-ID: <1478243599.2126.1.camel@gnutls.org> Hello,? ?I've just released gnutls 2.12.24. This is an update on the long-time deprecated 2.12.x branch. It fixes several interoperatibility issues present at this branch, removes support for legacy protocols and ciphersuites, and improves TLS 1.2 support. The update on this branch does not put 2.12.x into the maintained branches but it is rather a one-time update (sponsored by Red Hat) to extend the lifetime of systems which cannot upgrade to newer supported releases due to the ABI breakage. There are no other planned updates. Version 2.12.24 (released 2016-11-04) ** libgnutls: Fix in TLS server hello parsing (GNUTLS-SA-2014-3) ** libgnutls: Fix in TLS record decoding (GNUTLS-SA-2013-2) ** libgnutls: Fix in certificate verification (GNUTLS-SA-2014-1, ???GNUTLS-SA-2014-2, GNUTLS-SA-2015-1) ** libgnutls: Fix for MD5 downgrade in TLS 1.2 signatures. Reported by ???Karthikeyan Bhargavan (GNUTLS-SA-2015-2). ** libgnutls: Separated the logic of supported signature algorithms for ???CertificateRequest message and ClientHello. This allows the former ???be restricted to SHA1 and SHA256 due to internal limitations, while the ???latter can utilize any supported algorithms. ** libgnutls: Be less strict in TLS 1.2 signature algorithm adherence. This ???improves compatibility with sites that have a certificate with an enabled ???hash algorithm but necessarily enabled for TLS negotiation. ** libgnutls: No longer set SSL 3.0 as the record layer version by default ???This improves interoperability against broken servers which ???assume that this version is supported by the client. ** libgnutls: No longer include SSL 3.0 to the default protocol list. ???SSL 3.0 it must be explicitly enabled using a priority string. ** libgnutls: Prohibit DSA2 signatures when used with the libgcrypt ???backend. There are interoperability issues, and these algorithms are ???too rare to require a proper fix. ** libgnutls: The minimum Diffie-Hellman bits size was raised to 1023 from ???768. ** libgnutls: Removed support for EXPORT ciphersuites. The EXPORT priority ???string becomes an alias to NORMAL. ** libgnutls: Disabled random padding in the TLS protocol to improve compatibility ???with various broken servers. ** libgnutls: the ARCFOUR-128 cipher was removed from the default priority lists. ** libgnutls: Do not call the post client hello callback twice when resuming ???using session tickets. ** libgnutls: Corrected the setting of PSK hint for DHE-PSK ciphersuites. ** libgnutls: Do not link with libpthread unless necessary. ** libgnutls: Introduced the priority strings KX-ALL, VERS-ALL, CURVE-ALL (no-op) ???to improve compatibility with later versions of gnutls. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded directly from .??A list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v2.12/gnutls-2.12.24.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v2.12/gnutls-2.12.24.tar.xz.sig Note that it has been signed with my openpgp key: pub???3104R/96865171 2008-05-04 [expires: 2028-04-29] uid??????????????????Nikos Mavrogiannopoulos gnutls.org> uid??????????????????Nikos Mavrogiannopoulos gmail.com> sub???2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub???2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Fri Nov 4 08:28:02 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 04 Nov 2016 08:28:02 +0100 Subject: [gnutls-help] gnutls 3.5.6 Message-ID: <1478244482.2126.3.camel@gnutls.org> Hello,? ?I've just released gnutls 3.5.6. This is an enhancements and bugfix release for the 3.5.x branch. * Version 3.5.6 (released 2016-11-04) ** libgnutls: Enhanced the PKCS#7 parser to allow decoding old ???(pre-rfc5652) structures with arbitrary encapsulated content. ** libgnutls: Introduced a function group to set known DH parameters ???using groups from RFC7919. ** libgnutls: Added more strict RFC4514 textual DN encoding and decoding. ???Now the generated textual DN is in reverse order according to RFC4514, ???and functions which generate a DN from strings such gnutls_x509_crt_set_*dn() ???set the expected DN (reverse of the provided string). ** libgnutls: Introduced time and constraints checks in the end certificate ???in the gnutls_x509_crt_verify_data2() and gnutls_pkcs7_verify_direct() ???functions. ** libgnutls: Set limits on the maximum number of alerts handled. That is, ???applications using gnutls could be tricked into an busy loop if the ???peer sends continuously alert messages. Applications which set a maximum ???handshake time (via gnutls_handshake_set_timeout) will eventually recover ???but others may remain in a busy loops indefinitely. This is related but ???not identical to CVE-2016-8610, due to the difference in alert handling ???of the libraries (gnutls delegates that handling to applications). ** libgnutls: Reverted the change which made the gnutls_certificate_set_*key*? ???functions return an index (introduced in 3.5.5), to avoid affecting programs ???which explicitly check success of the function as equality to zero. In order ???for these functions to return an index an explicit call to gnutls_certificate_set_flags ???with the GNUTLS_CERTIFICATE_API_V2 flag is now required. ** libgnutls: Reverted the behavior of sending a status request extension even ???without a response (introduced in 3.5.5). That is, we no longer reply to a ???client's hello with a status request, with a status request extension. Although ???that behavior is legal, it creates incompatibility issues with releases in ???the gnutls 3.3.x branch. ** libgnutls: Delayed the initialization of the random generator at ???the first call of gnutls_rnd(). This allows applications to load ???on systems which getrandom() would block, without blocking until ???real random data are needed. ** certtool: --get-dh-params will output parameters from the RFC7919 ???groups. ** p11tool: improvements in --initialize option. ** API and ABI modifications: GNUTLS_CERTIFICATE_API_V2: Added GNUTLS_NO_TICKETS: Added gnutls_pkcs7_get_embedded_data_oid: Added gnutls_anon_set_server_known_dh_params: Added gnutls_certificate_set_known_dh_params: Added gnutls_psk_set_server_known_dh_params: Added gnutls_x509_crt_check_key_purpose: Added Getting the Software ==================== GnuTLS may be downloaded directly from .??A list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.6.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.6.tar.xz.sig Note that it has been signed with my openpgp key: pub???3104R/96865171 2008-05-04 [expires: 2028-04-29] uid??????????????????Nikos Mavrogiannopoulos gnutls.org> uid??????????????????Nikos Mavrogiannopoulos gmail.com> sub???2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub???2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Fri Nov 4 09:11:56 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 4 Nov 2016 09:11:56 +0100 Subject: [gnutls-help] Forcing chacha20-poly1305 In-Reply-To: References: Message-ID: On Thu, Nov 3, 2016 at 9:43 PM, James Cloos wrote: > I've tried quite a few priority strings to force chacha20-poly1305. > > It seems like it should be easier than: > SECURE256:+CHACHA20-POLY1305:-CAMELLIA-256-CBC:-CAMELLIA-256-GCM:-AES-256-CBC:-AES-256-GCM:-AES-256-CCM A simpler version is: "SECURE256:-CIPHER-ALL:+CHACHA20-POLY1305" > First, CHACHA20-POLY1305 ought to be part of SECURE256. Right, it seems it was only part of normal and performance strings. I'll check it. regards, Nikos From cloos at jhcloos.com Fri Nov 4 18:38:32 2016 From: cloos at jhcloos.com (James Cloos) Date: Fri, 04 Nov 2016 13:38:32 -0400 Subject: [gnutls-help] Forcing chacha20-poly1305 In-Reply-To: (Nikos Mavrogiannopoulos's message of "Fri, 4 Nov 2016 09:11:56 +0100") References: Message-ID: >>>>> "NM" == Nikos Mavrogiannopoulos writes: NM> A simpler version is: "SECURE256:-CIPHER-ALL:+CHACHA20-POLY1305" Oh. Duh. I managed to work out what I posted while I was writing the mail; I had tried -CIPHER-ALL before but hadn't though to try it with SECURE256.... [SIGH]. >> ... CHACHA20-POLY1305 ought to be part of SECURE256. NM> Right, it seems it was only part of normal and performance strings. NM> I'll check it. Thanks. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From cljung at live.se Thu Nov 10 20:36:51 2016 From: cljung at live.se (Christer Ljung) Date: Thu, 10 Nov 2016 19:36:51 +0000 Subject: [gnutls-help] known_hosts file format Message-ID: For a test case scenario, I'm trying to pre-creating the known_hosts file with entries. What is the data from the server's certificate that gets serialized in italic below? I haven't found any clear information about that anywhere. |g0|www.youtube.com|https|0|MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE7eUw+Kb3fhbNikivUBVwP1Rqn3EUL2AQULxRgcXUL1qYuP3GHcZNmSdtDvj7Dmr0MPBcKzZ69HyWeH08tCKTGg== Thanks! /C -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Fri Nov 11 08:57:39 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 11 Nov 2016 08:57:39 +0100 Subject: [gnutls-help] known_hosts file format In-Reply-To: References: Message-ID: On Thu, Nov 10, 2016 at 8:36 PM, Christer Ljung wrote: > For a test case scenario, I'm trying to pre-creating the known_hosts file > with entries. What is the data from the server's certificate that gets > serialized in italic below? I haven't found any clear information about that > anywhere. > |g0|www.youtube.com|https|0|MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE7eUw+Kb3fhbNikivUBVwP1Rqn3EUL2AQULxRgcXUL1qYuP3GHcZNmSdtDvj7Dmr0MPBcKzZ69HyWeH08tCKTGg== It should be |format-id|hostname|port or protocol|expiration in time_t| base64(der public key) If you have some suggestion on where this would be the expected place to be described let me know. regards, Nikos From ondrej at sury.org Sun Nov 13 07:20:06 2016 From: ondrej at sury.org (=?UTF-8?Q?Ond=C5=99ej=20Sur=C3=BD?=) Date: Sun, 13 Nov 2016 07:20:06 +0100 Subject: [gnutls-help] ED25519 status in GnuTLS Message-ID: <1479018006.2374580.785993985.4A600E18@webmail.messagingengine.com> Nikos, what's the current status of EdDSAS (Ed25519 and possibly Ed448) in GnuTLS? draft-irtf-cfrg-eddsa is in RFC Editor queue, that means only editorial changes are going to happen there. We are using: gnutls_pubkey_get_pk_ecc_raw gnutls_pubkey_import_ecc_raw gnutls_pubkey_get_pk_rsa_raw gnutls_pubkey_import_rsa_raw and I would love to have the EdDSA equivalents instead of going down for Nettle. (and for DNSSEC we need the Pure variants). Cheers, -- Ond?ej Sur? Knot DNS (https://www.knot-dns.cz/) ? a high-performance DNS server Knot Resolver (https://www.knot-resolver.cz/) ? secure, privacy-aware, fast DNS(SEC) resolver V?e pro chleba (https://vseprochleba.cz) ? Mouky ze ml?na a pot?eby pro pe?en? chleba v?eho druhu From n.mavrogiannopoulos at gmail.com Sun Nov 13 15:51:17 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sun, 13 Nov 2016 15:51:17 +0100 Subject: [gnutls-help] ED25519 status in GnuTLS In-Reply-To: <1479018006.2374580.785993985.4A600E18@webmail.messagingengine.com> References: <1479018006.2374580.785993985.4A600E18@webmail.messagingengine.com> Message-ID: <1479048677.22390.2.camel@gmail.com> On Sun, 2016-11-13 at 07:20 +0100, Ond?ej Sur? wrote: > Nikos, > > what's the current status of??EdDSAS (Ed25519 and possibly Ed448) in > GnuTLS? > > draft-irtf-cfrg-eddsa is in RFC Editor queue, that means only > editorial > changes > are going to happen there. > > We are using: > > gnutls_pubkey_get_pk_ecc_raw > gnutls_pubkey_import_ecc_raw > gnutls_pubkey_get_pk_rsa_raw > gnutls_pubkey_import_rsa_raw > > and I would love to have the EdDSA equivalents instead of going down > for Nettle. (and for DNSSEC we need the Pure variants). There is some testing code for EdDSA (non-pure variant) on a gitlab branch. It would most likely need some refresh, however, I haven't checked how and if the last version changed. The pure variant will need quite more changes since it cannot be used with gnutls_privkey_sign_hash(), but only with gnutls_privkey_sign_data() and we have to introduce this distinction internally. My plan is to introduce that feature on the next to 3.5.x branch once 3.5.x replaces the stable branch (around march). regards, Nikos From jrm at ftfl.ca Sun Nov 20 19:16:54 2016 From: jrm at ftfl.ca (Joseph Mingrone) Date: Sun, 20 Nov 2016 14:16:54 -0400 Subject: [gnutls-help] configure fails to detect trousers Message-ID: <86lgwenhih.fsf@phe.ftfl.ca> Hi, I'm attempting to fix a problem with the FreeBSD package for gnutls. Both gnutls and trousers have been updated to new versions recently (3.4.16 and trousers-0.3.13). Since then, gnutls fails to detect the trousers installation under /usr/local/. checking for tss library... no configure: WARNING: *** *** trousers was not found. TPM support will be disabled. *** A full build log can be found at http://pkg.awarnach.mathstat.dal.ca/data/11amd64-default/2016-11-20_12h45m57s/logs/errors/gnutls-3.4.16.log. If I'm missing any useful information, please let me know. Regards, Joseph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 930 bytes Desc: not available URL: From n.mavrogiannopoulos at gmail.com Mon Nov 21 21:39:52 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Mon, 21 Nov 2016 21:39:52 +0100 Subject: [gnutls-help] configure fails to detect trousers In-Reply-To: <86lgwenhih.fsf@phe.ftfl.ca> References: <86lgwenhih.fsf@phe.ftfl.ca> Message-ID: <1479760792.2939.6.camel@gmail.com> On Sun, 2016-11-20 at 14:16 -0400, Joseph Mingrone wrote: > Hi, > > I'm attempting to fix a problem with the FreeBSD package for > gnutls.??Both gnutls and trousers have been updated to new versions > recently (3.4.16 and trousers-0.3.13).??Since then, gnutls fails to > detect the trousers installation under /usr/local/. > > checking for tss library... no > configure: WARNING: > *** > *** trousers was not found. TPM support will be disabled. > *** > > A full build log can be found at http://pkg.awarnach.mathstat.dal.ca/ > data/11amd64-default/2016-11-20_12h45m57s/logs/errors/gnutls- > 3.4.16.log. > > If I'm missing any useful information, please let me know. Most likely the configure script failed to link with the system trousers library. Check config.log for the actual reason. regards, Nikos From Patrick.Ouellet at promutuel.ca Mon Nov 28 14:19:52 2016 From: Patrick.Ouellet at promutuel.ca (Patrick.Ouellet at promutuel.ca) Date: Mon, 28 Nov 2016 13:19:52 +0000 Subject: [gnutls-help] Issue using certtool Message-ID: I know this is quite an easy question for veteran of GNU TLS But im really used to openssl and a week ago I didn?t know there was an alternative to openssl So Im trying to build a ldap proxy using openldap the proxy works fine until I try to had TLS to it. The only error I could gather is this one. main: TLS init def ctx failed: -1 That?s when I realized Ubuntu compile openldap with gnutls not with openssl, so I wanted to verify my certificate to be sure gnutls can read and understand them. I just need help verifying my certificate using certool. I have been able to verify my CA cert At first it didn?t work certtool -e --infile certificate_chain.cer.pem Loaded 2 certificates, 1 CAs and 0 CRLs Subject: C=CA,ST=Quebec,L=Quebec,O=Promutuel CES,OU=Operations,CN=Promutuel HWS Root CA Issuer: C=CA,ST=Quebec,L=Quebec,O=Promutuel CES,OU=Operations,CN=Promutuel HWS Root CA Output: Not verified. The certificate is NOT trusted. The certificate issuer is unknown. Chain verification output: Not verified. The certificate is NOT trusted. The certificate issuer is unknown. Then I read somewhere, don?t ask me where, that gnutls need the certificate in the reverse order than openssl, so I inverted the certificate order in the certificate_chain.cer.pem and it worked certtool -e --infile certificate_chain.cer.pem.gnutls Loaded 2 certificates, 1 CAs and 0 CRLs Subject: C=CA,ST=Quebec,O=Promutuel CES,OU=Operations,CN=Promutuel HWS Intermediate CA 1 Issuer: C=CA,ST=Quebec,L=Quebec,O=Promutuel CES,OU=Operations,CN=Promutuel HWS Root CA Checked against: C=CA,ST=Quebec,L=Quebec,O=Promutuel CES,OU=Operations,CN=Promutuel HWS Root CA Output: Verified. The certificate is trusted. Chain verification output: Verified. The certificate is trusted. But when I try to verify my server certificate, no matter what I do I was unable to get a ?Output: Verified. The certificate is trusted.? certtool -e --infile p01ldp5001.cer.pem --load-ca-certificate=certificate_chain.cer.pem.gnutls |<1>| There was a non-CA certificate in the trusted list: C=CA,ST=Quebec,L=Quebec,O=Promutuel CES,OU=Operations,CN=p01ldp5001.services.local. Loaded 1 certificates, 1 CAs and 0 CRLs Subject: C=CA,ST=Quebec,L=Quebec,O=Promutuel CES,OU=Operations,CN=p01ldp5001.services.local Issuer: C=CA,ST=Quebec,O=Promutuel CES,OU=Operations,CN=Promutuel HWS Intermediate CA 1 Output: Not verified. The certificate is NOT trusted. The certificate issuer is unknown. Subject: C=CA,ST=Quebec,L=Quebec,O=Promutuel CES,OU=Operations,CN=p01ldp5001.services.local Issuer: C=CA,ST=Quebec,O=Promutuel CES,OU=Operations,CN=Promutuel HWS Intermediate CA 1 Output: Not verified. The certificate is NOT trusted. The certificate issuer is unknown. Chain verification output: Not verified. The certificate is NOT trusted. The certificate issuer is unknown. Can somone help me with that? Is it my files that are not correct? Am I using some parameter wrong? Patrick Ouellet [ligne] Administrateur Linux Operation VPSI [promutuel-assurance] Groupe Promutuel 2000, boulevard Lebourgneuf, 4e ?tage, Qu?bec (Qu?bec) G2K 0B6 [tel] 418 840-1188, poste 2393 / 1 800 510-4630 [telec] 418 840-9900 promutuelassurance.ca Si vous devez imprimer ce document, faites-le recto verso. Si vous n'?tes pas le destinataire de ce message, veuillez le d?truire apr?s avoir inform? l'exp?diteur de son erreur. Par ailleurs, il est interdit de copier ou de modifier tout courriel sans l'autorisation de l'auteur. Promutuel Assurance n'assume aucune responsabilit? ? l'?gard du contenu des messages personnels envoy?s par ses employ?s. If you need to print this document, please print it double-sided. If you are not the intended recipient of this message, please notify the sender of the error and destroy the message. Please further note that it is prohibited to copy or modify any email without the author?s permission. Promutuel Insurance accepts no liability whatsoever with regard to the content of personal messages sent by its employees. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 1164 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 3443 bytes Desc: image002.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.gif Type: image/gif Size: 1366 bytes Desc: image003.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.gif Type: image/gif Size: 1364 bytes Desc: image004.gif URL: From nmav at gnutls.org Tue Nov 29 15:34:29 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 29 Nov 2016 15:34:29 +0100 Subject: [gnutls-help] Issue using certtool In-Reply-To: References: Message-ID: On Mon, Nov 28, 2016 at 2:19 PM, wrote: > I know this is quite an easy question for veteran of GNU TLS > > But im really used to openssl and a week ago I didn?t know there was an > alternative to openssl > > > > So Im trying to build a ldap proxy using openldap the proxy works fine > until I try to had TLS to it. > > > > The only error I could gather is this one. > > > > main: TLS init def ctx failed: -1 > > > > That?s when I realized Ubuntu compile openldap with gnutls not with > openssl, so I wanted to verify my certificate > > to be sure gnutls can read and understand them. > > > > I just need help verifying my certificate using certool. > > > > I have been able to verify my CA cert > > > > At first it didn?t work > > > > certtool -e --infile certificate_chain.cer.pem > > Loaded 2 certificates, 1 CAs and 0 CRLs > > > > Subject: C=CA,ST=Quebec,L=Quebec,O=Promutuel > CES,OU=Operations,CN=Promutuel HWS Root CA > > Issuer: C=CA,ST=Quebec,L=Quebec,O=Promutuel > CES,OU=Operations,CN=Promutuel HWS Root CA > > Output: Not verified. The certificate is NOT trusted. The > certificate issuer is unknown. > > > > Chain verification output: Not verified. The certificate is NOT trusted. > The certificate issuer is unknown. > > > > Then I read somewhere, don?t ask me where, that gnutls need the > certificate in the reverse order than openssl, so > > I inverted the certificate order in the certificate_chain.cer.pem and it > worked > Note that certtool requires a sorted (starting from the end-certificate to root CA) chain. That is the chain order expected by TLS protocol (and that's the chain you should setup at your server). Note that newer versions of gnutls, will sort such lists as long as the end certificate is still first. certtool -e --infile certificate_chain.cer.pem.gnutls > > Loaded 2 certificates, 1 CAs and 0 CRLs > > > > Subject: C=CA,ST=Quebec,O=Promutuel CES,OU=Operations,CN=Promutuel > HWS Intermediate CA 1 > > Issuer: C=CA,ST=Quebec,L=Quebec,O=Promutuel > CES,OU=Operations,CN=Promutuel HWS Root CA > > Checked against: C=CA,ST=Quebec,L=Quebec,O=Promutuel > CES,OU=Operations,CN=Promutuel HWS Root CA > > Output: Verified. The certificate is trusted. > > > > Chain verification output: Verified. The certificate is trusted. > > But when I try to verify my server certificate, no matter what I do I was > unable to get a ?Output: Verified. The certificate is trusted.? > That means that the verification chain is correct (each certificate validates the one before that). It does not check if the intended hostname matches, or the certificate purpose is ok. To do that you need to use (in a recent gnutls version): $ certtool -e --infile chain.pem --verify-hostname localhost --verify-purpose 1.3.6.1.5.5.7.3.1 (the purpose 1.3.6.1.5.5.7.3.1 is for server TLS certificate) regards, Nikos -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrien.beraud at savoirfairelinux.com Wed Nov 30 22:15:41 2016 From: adrien.beraud at savoirfairelinux.com (Adrien =?utf-8?Q?B=C3=A9raud?=) Date: Wed, 30 Nov 2016 16:15:41 -0500 (EST) Subject: [gnutls-help] gnutls_x509_crl_verify fails for new generated certificates or CRL Message-ID: <1978943522.87471.1480540541189.JavaMail.zimbra@savoirfairelinux.com> I make use of GnuTLS certificate revocation list methods, including gnutls_x509_crl_verify, but it looks like there some issue: gnutls_x509_crl_verify calls find_crl_issuer, which calls is_crl_issuer, which calls _gnutls_x509_compare_raw_dn However it seems that the raw_dn field is not set for a new generated certificate, only for a certificate loaded using gnutls_x509_crt_import functions. Also it seems the raw_issuer_dn field is not set for a new generated CRL, only for a CRL loaded using gnutls_x509_crl_import functions. So that gnutls_x509_crl_verify fails when used with new generated certificate or CRL. Also this means that if multiple new certificates and a new CRL are provided to gnutls_x509_crl_verify, any of the provided certificate will match since the raw DN is allays empty so allays equal. Fortunately in this case the signature check would fail later in gnutls_x509_crl_verify so this might not be a security issue. Can you confirm the issue ? Thanks, Adrien Beraud Savoir-faire Linux -------------- next part -------------- An HTML attachment was scrubbed... URL: