From nmav at gnutls.org Mon Jan 9 09:01:02 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 09 Jan 2017 09:01:02 +0100
Subject: [gnutls-help] gnutls 3.3.26
Message-ID: <1483948862.3495.1.camel@gnutls.org>
Hello,?
?I've just released gnutls 3.3.26. This is a bug-fix release on
the previous stable branch which addresses GNUTLS-SA-2017-1, and
GNUTLS-SA-2017-2, while backports some functionality to enable certain
PKCS#11 smart card use-cases.
* Version 3.3.26 (released 2016-01-09)
** libgnutls: Handle status request responses as optional (following
RFC6066). This improves compatibility with implementations not sending
these messages (including specific versions of the GnuTLS 3.5.x branch).
** 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: Fixed issue in PKCS#12 password encoding, which truncated
passwords over 32-characters. Reported by Mario Klebsch.
** libgnutls: Backported functionality allowing to manipulate the IDs
of PKCS#11 objects.
** libgnutls: Link to trousers (TPM library) dynamically. Backported TPM
key handling improvements from master branch.
** libgnutls: Backported several fixes in PKCS#8 decryption (related to
gitlab issue #148).
** libgnutls: Fix double free in certificate information printing. If the PKIX
extension proxy was set with a policy language set but no policy specified,
that could lead to a double free. [GNUTLS-SA-2017-1]
** libgnutls: Addressed memory leak in server side error path
(issue found using oss-fuzz project)
** libgnutls: Addressed memory leaks and an infinite loop in OpenPGP certificate
parsing. Fixes by Alex Gaynor. (issues found using oss-fuzz project)
** libgnutls: Addressed invalid memory accesses in OpenPGP certificate parsing.
(issues found using oss-fuzz project) [GNUTLS-SA-2017-2]
** tpmtool: backported the --test-sign option.
** API and ABI modifications:
gnutls_pkcs11_obj_set_info: Added
gnutls_pkcs11_privkey_generate3: Added
gnutls_pkcs11_copy_x509_privkey2: Added
gnutls_pkcs11_copy_x509_crt2: 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.3/gnutls-3.3.26.tar.xz
Here are OpenPGP detached signatures signed using key 0x96865171:
? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.26.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 Mon Jan 9 09:17:16 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 09 Jan 2017 09:17:16 +0100
Subject: [gnutls-help] gnutls 3.5.8
Message-ID: <1483949836.3495.3.camel@gnutls.org>
Hello,?
?I've just released gnutls 3.5.8. This is a bug fix release, and is also
the release in the 3.5.x marked as stable. As such the 3.5.x fully replaces
the (ABI-compatible) 3.4.x branch which will no longer receive updates.
Several issues fixed at this release were found using the oss-fuzz project.
I'd like to thank Alex Gaynor for bringing gnutls to OSS-FUZZ and fixing
issues. The existing fuzzers for gnutls/ are available on the devel/fuzz
directory in the master branch.
* Version 3.5.8 (released 2016-01-09)
** libgnutls: Ensure that multiple calls to the gnutls_set_priority_*
???functions will not leave the verification profiles field to an
???undefined state. The last call will take precedence.
** libgnutls: Ensure that GNUTLS_E_DECRYPTION_FAIL will be returned
???by PKCS#8 decryption functions when an invalid key is provided. This
???addresses regression on decrypting certain PKCS#8 keys.
** libgnutls: Introduced option to override the default priority string
???used by the library. The intention is to allow support of system-wide
???priority strings (as set with --with-system-priority-file). The
???configure option is --with-default-priority-string.
** libgnutls: Require a valid IV size on all ciphers for PKCS#8 decryption.
???This prevents crashes when decrypting malformed PKCS#8 keys.
(issue found using oss-fuzz project)
** libgnutls: Fix crash on the loading of malformed private keys with certain
???parameters set to zero. (issue found using oss-fuzz project)
** libgnutls: Fix double free in certificate information printing. If the PKIX
???extension proxy was set with a policy language set but no policy specified,
???that could lead to a double free. (issue found using oss-fuzz project)
** libgnutls: Addressed memory leaks in client and server side error paths
???(issues found using oss-fuzz project)
** libgnutls: Addressed memory leaks in X.509 certificate printing error paths
???(issues found using oss-fuzz project)
** libgnutls: Addressed memory leaks and an infinite loop in OpenPGP certificate
???parsing. Fixes by Alex Gaynor. (issues found using oss-fuzz project)
** libgnutls: Addressed invalid memory accesses in OpenPGP certificate parsing.
???(issues found using oss-fuzz project)
** 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/v3.5/gnutls-3.5.8.tar.xz
Here are OpenPGP detached signatures signed using key 0x96865171:
? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.8.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 Mon Jan 9 09:25:10 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 9 Jan 2017 09:25:10 +0100
Subject: [gnutls-help] gnutls 3.5.8
In-Reply-To: <1483949836.3495.3.camel@gnutls.org>
References: <1483949836.3495.3.camel@gnutls.org>
Message-ID:
On Mon, Jan 9, 2017 at 9:17 AM, Nikos Mavrogiannopoulos wrote:
> ** libgnutls: Fix double free in certificate information printing. If the PKIX
> extension proxy was set with a policy language set but no policy specified,
> that could lead to a double free. (issue found using oss-fuzz project)
>
> ** libgnutls: Addressed invalid memory accesses in OpenPGP certificate parsing.
> (issues found using oss-fuzz project)
Note that I forgot to refer to GNUTLS-SA-2017-1 and GNUTLS-SA-2017-2 for these
two issues.
regards,
Nikos
From jblasi at nextel.es Mon Jan 16 09:12:53 2017
From: jblasi at nextel.es (Jordi Blasi Uribarri)
Date: Mon, 16 Jan 2017 08:12:53 +0000
Subject: [gnutls-help] Obtain CN from session certificate
Message-ID:
Hi,
I am trying to adapt some other developers project and my understanding of the process is not complete. I have compiled and run the FreeCoap project that uses GNUTLS to stablish a DTLS session to comunicate between peers. At the present, the code negotiates the keys using x.509 certificates and sends information correctly. The keys are generated with the following command:
certtool --generate-privkey --ecc --curve secp256r1 --outfile client_privkey.pem
certtool --generate-certificate --ecc --curve secp256r1 --template client_template.txt --outfile client_cert.pem --load-privkey client_privkey.pem --load-ca_certificate root_client_cert.pem --load-ca-privkey root_client_privkey.pem
being the client_template.txt content this:
organization="Dummy"
unit="Software"
cn="dummy/client"
expiration_days="3650"
tls_www_client
What I want is to obtain in the code the information relative to the requester, this means, the cn, unit, and organization.
After succesfully negotiating the handshake I see that I have a gnutls_session_t object available, that I understand should contain this information. I see that it obtains different values using different methods:
gnutls_session_t session;
gnutls_cipher_algorithm_t cipher = 0;
gnutls_mac_algorithm_t mac = 0;
gnutls_kx_algorithm_t kx = 0;
const char *cipher_suite = NULL;
...
kx = gnutls_kx_get(session);
cipher = gnutls_cipher_get(session);
mac = gnutls_mac_get(session);
cipher_suite = gnutls_cipher_suite_get_name(kx, cipher, mac);
I have been navigating through the gnutls man pages but I have not found a way to obtain this information. Any idea of how to get to it? I am missunderstanding something?
Thanks for your help,
Jordi
________________________________
Jordi Blasi Uribarri
?rea I+D+i
jblasi at nextel.es
Oficina Bilbao
[http://www.nextel.es/wp-content/uploads/Firma_Nextel_2015.png]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From nmav at gnutls.org Mon Jan 16 19:35:16 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 16 Jan 2017 19:35:16 +0100
Subject: [gnutls-help] Obtain CN from session certificate
In-Reply-To:
References:
Message-ID: <1484591716.24301.4.camel@gnutls.org>
On Mon, 2017-01-16 at 08:12 +0000, Jordi Blasi Uribarri wrote:
> Hi,
> ?
> I am trying to adapt some other developers project and my
> understanding of the process is not complete. I have compiled and run
> the FreeCoap project that uses GNUTLS to stablish a DTLS session to
> comunicate between peers. At the present, the code negotiates the
> keys using x.509 certificates and sends information correctly. The
> keys are generated with the following command:
> [...]
> What I want is to obtain in the code the information relative to the
> requester, this means, the cn, unit, and organization.
I'd suggest to read the manual. While extensive it has quite some
examples. You'll need to get the peer's certificate and parse it. For
start check gnutls_certificate_get_peers().
regards,
Nikos
From jblasi at nextel.es Tue Jan 17 15:48:06 2017
From: jblasi at nextel.es (Jordi Blasi Uribarri)
Date: Tue, 17 Jan 2017 14:48:06 +0000
Subject: [gnutls-help] Obtain CN from session certificate
In-Reply-To: <1484591716.24301.4.camel@gnutls.org>
References:
<1484591716.24301.4.camel@gnutls.org>
Message-ID:
I got the code from one of those examples and when arriving to the gnutls_certificate_get_peers function I get a "No certificate was found" error.
cert_list = gnutls_certificate_get_peers( trans->session, &cert_list_size);
if ( cert_list == NULL) {
coap_log_error("No certificate was found!\n");
return -1;
}
The client goes throguh the following steps. I removed error control and extra code for simplicity.
ret = gnutls_global_init();
ret = gnutls_certificate_allocate_credentials(&client->cred);
ret = gnutls_certificate_set_x509_trust_file(client->cred, trust_file_name, GNUTLS_X509_FMT_PEM);
ret = gnutls_certificate_set_x509_crl_file(client->cred, crl_file_name, GNUTLS_X509_FMT_PEM);
ret = gnutls_certificate_set_x509_key_file(client->cred, cert_file_name, key_file_name, GNUTLS_X509_FMT_PEM);
ret = gnutls_priority_init(&client->priority, COAP_CLIENT_DTLS_PRIORITIES, NULL);
ret = gnutls_init(&client->session, GNUTLS_CLIENT | GNUTLS_DATAGRAM | GNUTLS_NONBLOCK);
ret = gnutls_credentials_set(client->session, GNUTLS_CRD_CERTIFICATE, client->cred);
ret = gnutls_priority_set(client->session, client->priority);
gnutls_transport_set_ptr(client->session, client);
gnutls_transport_set_pull_function(client->session, coap_client_dtls_pull_func);
gnutls_transport_set_pull_timeout_function(client->session, coap_client_dtls_pull_timeout_func);
gnutls_transport_set_push_function(client->session, coap_client_dtls_push_func);
gnutls_dtls_set_mtu(client->session, COAP_CLIENT_DTLS_MTU);
gnutls_dtls_set_timeouts(client->session, COAP_CLIENT_DTLS_RETRANS_TIMEOUT, COAP_CLIENT_DTLS_TOTAL_TIMEOUT);
ret = gnutls_handshake(client->session);
I have been checking with another client example in the manual and I see nowhere I am doing things differently.
any idea where my mistake is?
thanks.
Jordi
-----Mensaje original-----
De: Gnutls-help [mailto:gnutls-help-bounces at lists.gnutls.org] En nombre de Nikos Mavrogiannopoulos
Enviado el: lunes, 16 de enero de 2017 19:35
Para: gnutls-help at lists.gnutls.org
Asunto: Re: [gnutls-help] Obtain CN from session certificate
On Mon, 2017-01-16 at 08:12 +0000, Jordi Blasi Uribarri wrote:
> Hi,
> ?
> I am trying to adapt some other developers project and my
> understanding of the process is not complete. I have compiled and run
> the FreeCoap project that uses GNUTLS to stablish a DTLS session to
> comunicate between peers. At the present, the code negotiates the keys
> using x.509 certificates and sends information correctly. The keys are
> generated with the following command:
> [...]
> What I want is to obtain in the code the information relative to the
> requester, this means, the cn, unit, and organization.
I'd suggest to read the manual. While extensive it has quite some examples. You'll need to get the peer's certificate and parse it. For start check gnutls_certificate_get_peers().
regards,
Nikos
_______________________________________________
Gnutls-help mailing list
Gnutls-help at lists.gnutls.org
http://lists.gnupg.org/mailman/listinfo/gnutls-help
From grin at grin.hu Wed Jan 18 14:02:58 2017
From: grin at grin.hu (Peter Gervai)
Date: Wed, 18 Jan 2017 14:02:58 +0100
Subject: [gnutls-help] certtool generate-dh-params is fast,
but is it secret? is it safe?
Message-ID:
Hello,
I've tried to look around for some info, but found none.
openssl dhparam -out /tmp/dh4096.pem 4096
takes tens of minutes, while
certtool --generate-dh-params --bits 4096 > /tmp/dh4096.pem
takes 2 seconds. I guess this was probably noticed by someone else,
too, and it has been asked a few times but I see no answer.
Openssl say it's looking for safe primes, and does it for quite a long
time. I would guess that certtol either know a groundbreaking new way
to find safe primes or doesn't bother at all? As my understanding goes
generating DH params with not safe primes is not very useful?
Please show me the light.
Thanks,
Peter
From nmav at gnutls.org Sun Jan 22 01:06:38 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 22 Jan 2017 01:06:38 +0100
Subject: [gnutls-help] certtool generate-dh-params is fast,
but is it secret? is it safe?
In-Reply-To:
References:
Message-ID:
On Wed, Jan 18, 2017 at 2:02 PM, Peter Gervai wrote:
> Hello,
>
> I've tried to look around for some info, but found none.
I believe that you misunderstand what these parameters are and how are
they used.
There is some older blog discussing some details:
http://nmav.gnutls.org/2011/12/generating-diffie-hellman-parameters.html
However it is not accurate since then nettle already supports DH
parameter generation and that's the DSA-style of DH parameters.
But it doesn't matter. If you are generating random parameters, don't do it.
https://gitlab.com/gnutls/gnutls/commit/63b4a81a107101e3a4517d0402e494983700714d#04efa6908cdf650892ddc97766b5fadce0048fc0_1720_1717
regards,
Nikos
From olivier.soldano at savoirfairelinux.com Tue Jan 24 16:17:52 2017
From: olivier.soldano at savoirfairelinux.com (Olivier Soldano)
Date: Tue, 24 Jan 2017 10:17:52 -0500 (EST)
Subject: [gnutls-help] gnutls_heartbeat_ping data_size parameter
documentation
Message-ID: <424816726.57788.1485271072081.JavaMail.zimbra@savoirfairelinux.com>
Hello,
I am currently having some trouble with the documentation of gnutls_heartbeat_ping.
It is said that : size_t data_size
is the length of the ping payload.
I thought it meant the effective size of the Heartbeat packet generated,
but my numbers are off. a little example:
- I specify a data_size of 444 bytes,
- I end up with an encrypted message of 471 bytes and a TLS packet of 489 bytes.
which after analysis ought to be the TLS header size and the MAC + padding in the
encryption algorithm used.
I don't understand where is my error, as i thought that the tls header size
was covered by DEFAULT_PAYLOAD_SIZE in heartbeat_send_data. I think this is a mixed signal between
the documentation and implementation.
If these numbers are to be taken into account, I think that the documentation should states so.
If anybody has piece of advice on the subject, I would be more than content to hear it!
Olivier Soldano
From nmav at gnutls.org Wed Jan 25 16:09:42 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 25 Jan 2017 16:09:42 +0100
Subject: [gnutls-help] gnutls_heartbeat_ping data_size parameter
documentation
In-Reply-To: <424816726.57788.1485271072081.JavaMail.zimbra@savoirfairelinux.com>
References: <424816726.57788.1485271072081.JavaMail.zimbra@savoirfairelinux.com>
Message-ID:
On Tue, Jan 24, 2017 at 4:17 PM, Olivier Soldano
wrote:
> Hello,
> I am currently having some trouble with the documentation of gnutls_heartbeat_ping.
> It is said that : size_t data_size
> is the length of the ping payload.
>
> I thought it meant the effective size of the Heartbeat packet generated,
> but my numbers are off. a little example:
>
> - I specify a data_size of 444 bytes,
> - I end up with an encrypted message of 471 bytes and a TLS packet of 489 bytes.
Is that the same as the size you specified + the output of
gnutls_record_overhead_size()?
> which after analysis ought to be the TLS header size and the MAC + padding in the
> encryption algorithm used.
> I don't understand where is my error, as i thought that the tls header size
> was covered by DEFAULT_PAYLOAD_SIZE in heartbeat_send_data. I think this is a mixed signal between
Do you mean the DEFAULT_PADDING_SIZE? That's a weird overhead due to
the way the heartbeat extension is defined (normal payload + some
padding). gnutls attempts to hide that padding size as it makes no
sense for applications.
regards,
Nikos
From olivier.soldano at savoirfairelinux.com Wed Jan 25 17:56:05 2017
From: olivier.soldano at savoirfairelinux.com (Olivier Soldano)
Date: Wed, 25 Jan 2017 11:56:05 -0500 (EST)
Subject: [gnutls-help] gnutls_heartbeat_ping data_size parameter
documentation
In-Reply-To:
References: <424816726.57788.1485271072081.JavaMail.zimbra@savoirfairelinux.com>
Message-ID: <581660493.146543.1485363365687.JavaMail.zimbra@savoirfairelinux.com>
Hello Nikos,
Thanks for your answer, first let me apologize for the typos,
yes I meant DEFAULT_PADDING_SIZE and the effective packet size is 484 with a specified data size of 444.
The output of gnutls_record_overhead_size is 37 which is off by 3.
However 37 seams to be correct as the sessions sends DTLS packets (DTLS_RECORD_HEADER_SIZE = 13) and is cyphered using AES-256-GCM
with AEAD MAC (24 bytes of overhead) which is indeed 37 bytes.
Maybe it is linked to : response = gnutls_malloc(1 + 2 + data_size + DEFAULT_PADDING_SIZE) in heartbeat_send_data ?
some logs with the same data_size of 444:
[5]GnuTLS: REC[0x7fc6040087a0]: Preparing Packet HeartBeat(24) with length: 447 and min pad: 0
[9]GnuTLS: ENC[0x7fc6040087a0]: cipher: AES-256-GCM, MAC: AEAD, Epoch: 2
[5]GnuTLS: REC[0x7fc6040087a0]: Sent Packet[2] HeartBeat(24) in epoch 2 and length: 484
[5]GnuTLS: REC[0x7fc6040087a0]: SSL 254.253 HeartBeat packet received. Epoch 2, length: 471
[5]GnuTLS: REC[0x7fc6040087a0]: Expected Packet HeartBeat(24)
[5]GnuTLS: REC[0x7fc6040087a0]: Received Packet HeartBeat(24) with length: 471
[5]GnuTLS: REC[0x7fc6040087a0]: Decrypted Packet[2.1] HeartBeat(24) with length: 447
regards,
Olivier Soldano
----- Mail original -----
De: "Nikos Mavrogiannopoulos"
?: "Olivier Soldano"
Cc: "gnutls-help"
Envoy?: Mercredi 25 Janvier 2017 10:09:42
Objet: Re: [gnutls-help] gnutls_heartbeat_ping data_size parameter documentation
On Tue, Jan 24, 2017 at 4:17 PM, Olivier Soldano
wrote:
> Hello,
> I am currently having some trouble with the documentation of gnutls_heartbeat_ping.
> It is said that : size_t data_size
> is the length of the ping payload.
>
> I thought it meant the effective size of the Heartbeat packet generated,
> but my numbers are off. a little example:
>
> - I specify a data_size of 444 bytes,
> - I end up with an encrypted message of 471 bytes and a TLS packet of 489 bytes.
Is that the same as the size you specified + the output of
gnutls_record_overhead_size()?
> which after analysis ought to be the TLS header size and the MAC + padding in the
> encryption algorithm used.
> I don't understand where is my error, as i thought that the tls header size
> was covered by DEFAULT_PAYLOAD_SIZE in heartbeat_send_data. I think this is a mixed signal between
Do you mean the DEFAULT_PADDING_SIZE? That's a weird overhead due to
the way the heartbeat extension is defined (normal payload + some
padding). gnutls attempts to hide that padding size as it makes no
sense for applications.
regards,
Nikos
From nmav at gnutls.org Thu Jan 26 14:47:43 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 26 Jan 2017 14:47:43 +0100
Subject: [gnutls-help] gnutls_heartbeat_ping data_size parameter
documentation
In-Reply-To: <581660493.146543.1485363365687.JavaMail.zimbra@savoirfairelinux.com>
References: <424816726.57788.1485271072081.JavaMail.zimbra@savoirfairelinux.com>
<581660493.146543.1485363365687.JavaMail.zimbra@savoirfairelinux.com>
Message-ID:
On Wed, Jan 25, 2017 at 5:56 PM, Olivier Soldano
wrote:
> Hello Nikos,
>
> Thanks for your answer, first let me apologize for the typos,
> yes I meant DEFAULT_PADDING_SIZE and the effective packet size is 484 with a specified data size of 444.
>
> The output of gnutls_record_overhead_size is 37 which is off by 3.
> However 37 seams to be correct as the sessions sends DTLS packets (DTLS_RECORD_HEADER_SIZE = 13) and is cyphered using AES-256-GCM
> with AEAD MAC (24 bytes of overhead) which is indeed 37 bytes.
> Maybe it is linked to : response = gnutls_malloc(1 + 2 + data_size + DEFAULT_PADDING_SIZE) in heartbeat_send_data ?
Right these are a header to the payload. So the number of data
transmitted by this function should be:
MAX(16, payload_size)+gnutls_record_overhead_size()+3.
I'll document that in gnutls_heartbeat_ping().
regards,
Nikos
From emailmandar at gmail.com Fri Jan 27 07:30:39 2017
From: emailmandar at gmail.com (Mandar Joshi)
Date: Fri, 27 Jan 2017 12:00:39 +0530
Subject: [gnutls-help] Verifying Client Certificate
Message-ID:
Hello everyone,
I am using GnuTLS functions in my glib and gio code to handle secure
connections.
I have a question about how to handle client authentication after I
have verified that the client certificate is valid.
In my server, I have set the client to require a certificate with
gnutls_certificate_server_set_request(client->session, GNUTLS_CERT_REQUIRE);
I used the code on
https://www.gnutls.org/manual/html_node/Verifying-a-certificate.html#Verifying-a-certificate
and I am able to verify whether the client certificate is valid or
invalid.
Now, what do I do once i have determined that the certificate is
valid. Which function should I call to tell GnuTLS library that the
certificate is valid and it can proceed with the connection?
Regards
Mandar Joshi
From emailmandar at gmail.com Fri Jan 27 11:48:21 2017
From: emailmandar at gmail.com (Mandar Joshi)
Date: Fri, 27 Jan 2017 16:18:21 +0530
Subject: [gnutls-help] Verifying Client Certificate
In-Reply-To:
References:
Message-ID:
Hello everyone,
There is a problem with my certificate. I was using my CA Cert to
connect to a server.
gnutls-serv reported "Key usage violation detected." which probably
means that I cannot use a signing certificate for establishing a TLS
connection.
I have now generated server and client certificates and will be
testing them with gnutls-serv and gnutls-cli
With the first client certs that I generated, gnutls-cli give me an error
-----------------------------------------------------------------------------
Status: The certificate is NOT trusted. The certificate issuer is
unknown. The name in the certificate does not match the expected.
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
*** handshake has failed: Error in the certificate.
-----------------------------------------------------------------------------
and gnutls-serv gave this error message
-----------------------------------------------------------------------------
* Accepted connection from IPv4 127.0.0.1 port 53074 on Fri Jan 27 15:58:58 2017
* Received alert '42': Certificate is bad.
Error in handshake
Error: A TLS fatal alert has been received.
-----------------------------------------------------------------------------
So, I guess the problem is with my certificate templates.
My requirement is that I should have a Certificate Authority that
generates certificates for Servers.
Each of there Servers will have multiple clients. The client
certificates should only work with their respective servers.
Are there any templates out there which have the right config for this
kind of setup?
Thanks
Mandar Joshi
From emailmandar at gmail.com Sat Jan 28 10:33:44 2017
From: emailmandar at gmail.com (Mandar Joshi)
Date: Sat, 28 Jan 2017 15:03:44 +0530
Subject: [gnutls-help] Verifying Client Certificate
In-Reply-To:
References:
Message-ID:
Hello again,
There was a problem with my certificates.
Followed the instructions on
https://www.gnutls.org/manual/html_node/gnutls_002dserv-Invocation.html
and everything works now.
I now need to figure out how to use this with Glib. Things would have
been simple has this ePass2003 token supported exporting of private
key.
If anyone has an idea on how to make this work with Glib, your tips
would be very much appreciated.
Regards
Mandar Joshi
From olivier.soldano at savoirfairelinux.com Mon Jan 30 19:45:21 2017
From: olivier.soldano at savoirfairelinux.com (Olivier Soldano)
Date: Mon, 30 Jan 2017 13:45:21 -0500 (EST)
Subject: [gnutls-help] DTLS heartbeat interoperability
Message-ID: <1858135788.403876.1485801921137.JavaMail.zimbra@savoirfairelinux.com>
Hello,
I'm trying to make a path MTU discovery via heartbeat but I'm struggling
with asymmetrical cases in heartbeat interoperability, namely when the client has hearbeat enabled,
but not the server; and vice-versa. Is there a way to get the information of this
interoperability with a hello message in gnutls - RFC 6520 like -? or to guess which extensions
are allowed in the current session?
Regards,
Olivier SOLDANO
From emailmandar at gmail.com Tue Jan 31 17:46:45 2017
From: emailmandar at gmail.com (Mandar Joshi)
Date: Tue, 31 Jan 2017 22:16:45 +0530
Subject: [gnutls-help] Getting Object Type From Usb Token
Message-ID:
Hello,
I want to retrieve the URLs and type of all objects in a token.
I am able to get the object list using
gnutls_pkcs11_obj_list_import_url4 (...) using the code in examples on
the gnutls website.
Now, while iterating over the object list, I tried using
-----------------------------------------------------------------------------------------------------
struct gnutls_pkcs11_obj_st *x = (struct gnutls_pkcs11_obj_st *) obj_list[i];
g_message ("Type: %d", x->type);
-----------------------------------------------------------------------------------------------------
but this gives me an error while compiling
--------------------------------------------------------------------------------------------------------
error: dereferencing pointer to incomplete type ?struct gnutls_pkcs11_obj_st?
g_message ("Type: %d", x->type);
--------------------------------------------------------------------------------------------------------
Is there a header file I am missing? I have the following in my code
#include
#include
Is there a simpler method to retrieve the type.?
I found gnutls_pkcs11_type_get_name (..) in the API docs but I can use
that only after I get the type enum.
pkcs11.h only contains
-------------------------------------------------------------------------------
struct gnutls_pkcs11_obj_st;
typedef struct gnutls_pkcs11_obj_st *gnutls_pkcs11_obj_t;
-------------------------------------------------------------------------------
There is no struct there as shown in the API docs
https://gnutls.org/reference/gnutls-pkcs11.html
Regards
Mandar Joshi