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