From nmav at gnutls.org Sat Oct 6 09:17:35 2007 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 6 Oct 2007 10:17:35 +0300 Subject: [Help-gnutls] Re: GNU TLS windows problem. In-Reply-To: <87abr8gqcl.fsf@mocca.josefsson.org> References: <87abr8gqcl.fsf@mocca.josefsson.org> Message-ID: <200710061017.35844.nmav@gnutls.org> On Thursday 27 September 2007, Simon Josefsson wrote: > You can use the --outder flag to certtool when generating the > certificate. > If you already have a client certificate for the mobile and want to > convert it to DER, use: > > $ certtool -i --infile IN.pem --outder --outfile OUT.der > > However, this doesn't seem to work! Mea culpa. The output is garbled > for some reason. Possibly the --outder flag doesn't work when > generating certificates either. I'll see if I can debug this. This was a problem because of the fprintf usage in the printing function. I replaced it with fwrite and it works correctly now! Nikos From rajeev.saini at tcs.com Mon Oct 8 12:50:17 2007 From: rajeev.saini at tcs.com (Rajeev Saini) Date: Mon, 8 Oct 2007 16:20:17 +0530 Subject: [Help-gnutls] Windows GnuTLS problem in handshaking. Message-ID: Hi, I have managed to make DER encoded certificate and named it SuplRootCert and put it in the mobile(client). My server uses cacert.pem, server-cert.pem and server-key.pem to run the server. All these certificates were nade using openssl. Now when both interacts and does handshaking, i am getting the following error message. |<2>| ASSERT: ../../../../src/gnutls-2.0.0/lib/x509/x509.c:219 |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/gnutls_cert.c:758 |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/auth_cert.c:932 |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/gnutls_kx.c:612 |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/gnutls_handshake.c:2568 |<6>| BUF[HSK]: Cleared Data from buffer Error in handshake Error: ASN1 parser: Error in TAG. |<4>| REC: Sending Alert[2|42] - Certificate is bad Please help me as as per my understanding the certificates i generated are fine. Regards, Rajeev Saini. ***************************************************************************************************** The whole log follows below:- C:\Program Files\GnuTLS-2.0.0\bin>gnutls-serv --http --port 7070 --debug 10 --x5 09cafile cacert.pem --x509keyfile server-key.pem --x509certfile server-cert.pem Set static Diffie Hellman parameters, consider --dhparams. Processed 1 CA certificate(s). HTTP Server ready. Listening to port '7070'. |<7>| READ: Got 5 bytes from 376 |<7>| READ: read 5 bytes from 376 |<7>| 0000 - 16 03 01 00 2d |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[ac08a8]: Expected Packet[0] Handshake(22) with length: 1 |<4>| REC[ac08a8]: Received Packet[0] Handshake(22) with length: 45 |<7>| READ: Got 45 bytes from 376 |<7>| READ: read 45 bytes from 376 |<7>| 0000 - 01 00 00 29 03 01 78 25 a3 00 d8 89 5b 0f a5 cd |<7>| 0001 - 9a 64 cd d3 f5 09 3e 6e 21 a1 77 3c 8c 37 d7 75 |<7>| 0002 - ec c4 37 bb 2e 8a 00 00 02 00 2f 01 00 |<7>| RB: Have 5 bytes into buffer. Adding 45 bytes. |<7>| RB: Requested 50 bytes |<4>| REC[ac08a8]: Decrypted Packet[0] Handshake(22) with length: 45 |<6>| BUF[HSK]: Inserted 45 bytes of Data(22) |<6>| BUF[REC][HD]: Read 1 bytes of Data(22) |<6>| BUF[REC][HD]: Read 3 bytes of Data(22) |<3>| HSK[ac08a8]: CLIENT HELLO was received [45 bytes] |<6>| BUF[REC][HD]: Read 41 bytes of Data(22) |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 41 bytes of Data |<3>| HSK[ac08a8]: Client's version: 3.1 |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/gnutls_db.c:327 |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/gnutls_db.c:247 |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/gnutls_algorithms.c:1628 |<3>| HSK[ac08a8]: Selected Compression Method: NULL |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/gnutls_extensions.c:162 |<3>| HSK[ac08a8]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1 |<3>| HSK[ac08a8]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1 |<3>| HSK[ac08a8]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1 |<3>| HSK[ac08a8]: Removing ciphersuite: PSK_SHA_AES_256_CBC_SHA1 |<3>| HSK[ac08a8]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1 |<3>| HSK[ac08a8]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1 |<3>| HSK[ac08a8]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1 |<3>| HSK[ac08a8]: Removing ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1 |<3>| HSK[ac08a8]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1 |<3>| HSK[ac08a8]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1 |<3>| HSK[ac08a8]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1 |<3>| HSK[ac08a8]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[ac08a8]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[ac08a8]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1 |<3>| HSK[ac08a8]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1 |<3>| HSK[ac08a8]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1 |<3>| HSK[ac08a8]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1 |<3>| HSK[ac08a8]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1 |<3>| HSK[ac08a8]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[ac08a8]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1 |<3>| HSK[ac08a8]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA1 |<3>| HSK[ac08a8]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[ac08a8]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 |<3>| HSK[ac08a8]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 |<3>| HSK[ac08a8]: Keeping ciphersuite: RSA_ARCFOUR_SHA1 |<3>| HSK[ac08a8]: Keeping ciphersuite: RSA_ARCFOUR_MD5 |<3>| HSK[ac08a8]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[ac08a8]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 |<3>| HSK[ac08a8]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 |<3>| HSK[ac08a8]: Selected cipher suite: RSA_AES_128_CBC_SHA1 |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/ext_authz.c:180 |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/ext_authz.c:237 |<3>| HSK[ac08a8]: SessionID: e9ad956af10609d73b39f39a960f0eae0d4991ff0ab5b17b4b 4ebabf77612277 |<3>| HSK[ac08a8]: SERVER HELLO was send [74 bytes] |<6>| BUF[HSK]: Peeked 45 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<4>| REC[ac08a8]: Sending Packet[0] Handshake(22) with length: 74 |<7>| WRITE: Will write 79 bytes to 376. |<7>| WRITE: wrote 79 bytes to 376. Left 0 bytes. Total 79 bytes. |<7>| 0000 - 16 03 01 00 4a 02 00 00 46 03 01 47 09 e3 c3 14 |<7>| 0001 - ce e2 9b 0c 6d fa f0 bd 49 ad aa e2 57 aa 15 63 |<7>| 0002 - 3b ad 3f c6 3a c4 c5 45 44 38 8f 20 e9 ad 95 6a |<7>| 0003 - f1 06 09 d7 3b 39 f3 9a 96 0f 0e ae 0d 49 91 ff |<7>| 0004 - 0a b5 b1 7b 4b 4e ba bf 77 61 22 77 00 2f 00 |<4>| REC[ac08a8]: Sent Packet[1] Handshake(22) with length: 79 |<3>| HSK[ac08a8]: CERTIFICATE was send [957 bytes] |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<4>| REC[ac08a8]: Sending Packet[1] Handshake(22) with length: 957 |<7>| WRITE: Will write 962 bytes to 376. |<7>| WRITE: wrote 962 bytes to 376. Left 0 bytes. Total 962 bytes. |<7>| 0000 - 16 03 01 03 bd 0b 00 03 b9 00 03 b6 00 03 b3 30 |<7>| 0001 - 82 03 af 30 82 02 97 a0 03 02 01 02 02 03 10 00 |<7>| 0002 - 02 30 0d 06 09 2a 86 48 86 f7 0d 01 01 05 05 00 |<7>| 0003 - 30 5a 31 0b 30 09 06 03 55 04 06 13 02 49 4e 31 |<7>| 0004 - 13 30 11 06 03 55 04 08 13 0a 53 6f 6d 65 2d 53 |<7>| 0005 - 74 61 74 65 31 21 30 1f 06 03 55 04 0a 13 18 49 |<7>| 0006 - 6e 74 65 72 6e 65 74 20 57 69 64 67 69 74 73 20 |<7>| 0007 - 50 74 79 20 4c 74 64 31 13 30 11 06 03 55 04 03 |<7>| 0008 - 13 0a 41 65 72 6f 66 6c 65 78 43 41 30 1e 17 0d |<7>| 0009 - 30 37 31 30 30 38 30 36 30 34 35 39 5a 17 0d 30 |<7>| 000a - 38 31 30 30 37 30 36 30 34 35 39 5a 30 5d 31 0b |<7>| 000b - 30 09 06 03 55 04 06 13 02 49 4e 31 13 30 11 06 |<7>| 000c - 03 55 04 08 13 0a 53 6f 6d 65 2d 53 74 61 74 65 |<7>| 000d - 31 21 30 1f 06 03 55 04 0a 13 18 49 6e 74 65 72 |<7>| 000e - 6e 65 74 20 57 69 64 67 69 74 73 20 50 74 79 20 |<7>| 000f - 4c 74 64 31 16 30 14 06 03 55 04 03 13 0d 31 37 |<7>| 0010 - 32 2e 32 31 2e 31 31 31 2e 37 30 30 82 01 22 30 |<7>| 0011 - 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 03 82 |<7>| 0012 - 01 0f 00 30 82 01 0a 02 82 01 01 00 c9 2f 29 c4 |<7>| 0013 - 88 0b 28 dd 7d 29 ec e9 2f e2 14 a0 49 aa e3 c2 |<7>| 0014 - a6 b5 63 57 f6 76 71 10 f8 8f ab 49 63 64 1c 50 |<7>| 0015 - 70 3a e6 9a 87 47 5f 75 77 1b 2c 43 76 a1 db f4 |<7>| 0016 - 05 89 61 d7 d0 8b 23 4e d0 9f 43 36 83 4c 3e 0f |<7>| 0017 - 5c 82 a6 eb 5e a3 90 3e 7c e1 29 4c 7b 4e 72 36 |<7>| 0018 - ad 27 0e 98 8a 2c cc 69 76 63 d6 00 75 03 95 01 |<7>| 0019 - 83 b9 56 0b 89 a0 fc d1 ac 86 74 52 8f 84 58 a8 |<7>| 001a - 54 b2 b4 2b 24 65 8f d0 5a 78 4b c1 e2 f8 c3 0e |<7>| 001b - 7e ed 2e ed aa cd 3a b5 ec 5e c0 86 0d f8 d6 7d |<7>| 001c - da e7 93 73 25 aa da 8b c0 6d 36 7e cc fb 35 01 |<7>| 001d - 27 9a ff 55 23 b9 70 83 83 af 44 af a6 63 cc 2b |<7>| 001e - 47 d4 9c 71 92 ad f1 32 b4 a8 bc 91 b2 9d d4 2e |<7>| 001f - ac 91 c4 82 39 83 79 6f 28 a5 fc 8a 7f 8e 44 2d |<7>| 0020 - 7b f9 c7 9c 31 0a 5d 72 01 e9 fa 69 fc f6 47 0e |<7>| 0021 - f7 9c 67 de 39 71 37 28 8d 7e fd 61 c4 6c c5 12 |<7>| 0022 - ed ce 38 0c dc b6 35 d3 43 12 54 ab 02 03 01 00 |<7>| 0023 - 01 a3 7b 30 79 30 09 06 03 55 1d 13 04 02 30 00 |<7>| 0024 - 30 2c 06 09 60 86 48 01 86 f8 42 01 0d 04 1f 16 |<7>| 0025 - 1d 4f 70 65 6e 53 53 4c 20 47 65 6e 65 72 61 74 |<7>| 0026 - 65 64 20 43 65 72 74 69 66 69 63 61 74 65 30 1d |<7>| 0027 - 06 03 55 1d 0e 04 16 04 14 ff df 1e b5 a2 2a 12 |<7>| 0028 - 78 d2 81 93 b1 1e a6 dd 3d 45 00 e3 31 30 1f 06 |<7>| 0029 - 03 55 1d 23 04 18 30 16 80 14 e6 06 b5 ed c8 09 |<7>| 002a - 7e 47 e2 b0 07 b0 46 f7 f2 5a ec 75 aa 7a 30 0d |<7>| 002b - 06 09 2a 86 48 86 f7 0d 01 01 05 05 00 03 82 01 |<7>| 002c - 01 00 8b 22 70 d4 c2 b5 3d 5d 7c f3 b6 c5 69 6a |<7>| 002d - 09 fd 2f ee 1a 7c 43 0e b6 37 df c0 98 e0 2c 5b |<7>| 002e - 26 58 be 19 33 35 47 45 81 68 cc 61 be 8f 15 aa |<7>| 002f - af fa f2 1d 5e 6a 05 83 0b 5a 2a e6 82 c1 22 8f |<7>| 0030 - ba c0 c1 b5 ea f4 30 14 de 3a 8c d6 bd 00 fb 68 |<7>| 0031 - c5 49 9a e6 30 86 ad 69 e0 21 74 06 1e 35 06 a7 |<7>| 0032 - e9 56 a1 ea 53 da c0 4b dc 52 13 02 1a 32 8f 44 |<7>| 0033 - 43 8c 9b d2 01 98 93 40 f9 64 4d 33 39 51 32 3c |<7>| 0034 - 53 ba 44 05 2e c6 d0 6f 61 a1 22 0b 07 f2 5e 4e |<7>| 0035 - bb 25 4f b7 d1 3f b1 81 f1 8b ce 27 6a 8f cc 44 |<7>| 0036 - 5b 4d aa 0c de cf e2 6d d4 d7 8d a7 e7 1d 89 f4 |<7>| 0037 - f7 1c a8 b0 62 3a ca 89 b4 57 5d 10 4a 77 8e c1 |<7>| 0038 - 95 42 ed 35 7a 60 e5 28 76 80 b0 41 c6 c7 9e 3f |<7>| 0039 - 93 bc 1c 29 f1 e1 77 b7 0c 98 39 18 97 54 7b f1 |<7>| 003a - 18 cf bb bc 71 05 12 3f 6b 14 03 21 b5 37 2d 86 |<7>| 003b - ff 68 c2 eb 24 76 0c 5a a5 1d b0 f1 ea ca 78 63 |<7>| 003c - bd 01 |<4>| REC[ac08a8]: Sent Packet[2] Handshake(22) with length: 962 |<3>| HSK[ac08a8]: CERTIFICATE REQUEST was send [103 bytes] |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<4>| REC[ac08a8]: Sending Packet[2] Handshake(22) with length: 103 |<7>| WRITE: Will write 108 bytes to 376. |<7>| WRITE: wrote 108 bytes to 376. Left 0 bytes. Total 108 bytes. |<7>| 0000 - 16 03 01 00 67 0d 00 00 63 02 01 02 00 5e 00 5c |<7>| 0001 - 30 5a 31 0b 30 09 06 03 55 04 06 13 02 49 4e 31 |<7>| 0002 - 13 30 11 06 03 55 04 08 13 0a 53 6f 6d 65 2d 53 |<7>| 0003 - 74 61 74 65 31 21 30 1f 06 03 55 04 0a 13 18 49 |<7>| 0004 - 6e 74 65 72 6e 65 74 20 57 69 64 67 69 74 73 20 |<7>| 0005 - 50 74 79 20 4c 74 64 31 13 30 11 06 03 55 04 03 |<7>| 0006 - 13 0a 41 65 72 6f 66 6c 65 78 43 41 |<4>| REC[ac08a8]: Sent Packet[3] Handshake(22) with length: 108 |<3>| HSK[ac08a8]: SERVER HELLO DONE was send [4 bytes] |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<4>| REC[ac08a8]: Sending Packet[3] Handshake(22) with length: 4 |<7>| WRITE: Will write 9 bytes to 376. |<7>| WRITE: wrote 9 bytes to 376. Left 0 bytes. Total 9 bytes. |<7>| 0000 - 16 03 01 00 04 0e 00 00 00 |<4>| REC[ac08a8]: Sent Packet[4] Handshake(22) with length: 9 |<7>| READ: Got 5 bytes from 376 |<7>| READ: read 5 bytes from 376 |<7>| 0000 - 16 03 01 00 0a |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[ac08a8]: Expected Packet[1] Handshake(22) with length: 1 |<4>| REC[ac08a8]: Received Packet[1] Handshake(22) with length: 10 |<7>| READ: Got 10 bytes from 376 |<7>| READ: read 10 bytes from 376 |<7>| 0000 - 0b 00 00 06 00 00 03 00 00 00 |<7>| RB: Have 5 bytes into buffer. Adding 10 bytes. |<7>| RB: Requested 15 bytes |<4>| REC[ac08a8]: Decrypted Packet[1] Handshake(22) with length: 10 |<6>| BUF[HSK]: Inserted 10 bytes of Data(22) |<6>| BUF[REC][HD]: Read 1 bytes of Data(22) |<6>| BUF[REC][HD]: Read 3 bytes of Data(22) |<3>| HSK[ac08a8]: CERTIFICATE was received [10 bytes] |<6>| BUF[REC][HD]: Read 6 bytes of Data(22) |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 6 bytes of Data |<2>| ASSERT: ../../../../src/gnutls-2.0.0/lib/x509/x509.c:219 |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/gnutls_cert.c:758 |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/auth_cert.c:932 |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/gnutls_kx.c:612 |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/gnutls_handshake.c:2568 |<6>| BUF[HSK]: Cleared Data from buffer Error in handshake Error: ASN1 parser: Error in TAG. |<4>| REC: Sending Alert[2|42] - Certificate is bad |<4>| REC[ac08a8]: Sending Packet[4] Alert(21) with length: 2 |<7>| WRITE: Will write 7 bytes to 376. |<7>| WRITE: wrote 7 bytes to 376. Left 0 bytes. Total 7 bytes. |<7>| 0000 - 15 03 01 00 02 02 2a |<4>| REC[ac08a8]: Sent Packet[5] Alert(21) with length: 7 |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/gnutls_record.c:241 =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon Oct 8 12:58:39 2007 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 8 Oct 2007 13:58:39 +0300 Subject: [Help-gnutls] Windows GnuTLS problem in handshaking. In-Reply-To: References: Message-ID: <200710081358.39577.nmav@gnutls.org> On Monday 08 October 2007, Rajeev Saini wrote: > Hi, > I have managed to make DER encoded certificate and named it SuplRootCert > and put it in the mobile(client). > My server uses cacert.pem, server-cert.pem and server-key.pem to run the > server. All these certificates were nade using openssl. > Now when both interacts and does handshaking, i am getting the following > error message. Please send the output of certtool -i of the certificates and the client certificate that cause problem. regards, Nikos From rajeev.saini at tcs.com Mon Oct 8 13:09:46 2007 From: rajeev.saini at tcs.com (Rajeev Saini) Date: Mon, 8 Oct 2007 16:39:46 +0530 Subject: [Help-gnutls] Windows GnuTLS problem in handshaking. In-Reply-To: <200710081358.39577.nmav@gnutls.org> Message-ID: C:\Program Files\GnuTLS-1.7.8\bin>certtool -i --inder --infile SuplRootCert X.509 Certificate Information: Version: 3 Serial Number (hex): 00a1c3ca47b2a81ba4 Issuer: C=IN,ST=Some-State,O=Internet Widgits Pty Ltd,CN=AeroflexCA Validity: Not Before: Mon Oct 06:01:04 UTC 2007 Not After: Tue Oct 06:01:04 UTC 2008 Subject: C=IN,ST=Some-State,O=Internet Widgits Pty Ltd,CN=AeroflexCA Subject Public Key Algorithm: RSA Modulus (bits 2048): bf:c8:3f:77:37:d6:06:40:2b:e4:6f:80:a3:07:5e:f5 4d:e6:c8:d1:b0:8d:0c:74:27:18:8c:d2:c1:18:63:19 ac:00:2f:c9:2d:32:de:35:e5:cd:80:97:7f:5f:90:b1 d0:98:84:a0:44:96:98:83:22:f0:ac:04:5e:a6:fa:46 62:63:7a:d6:a5:d2:4d:df:d2:e6:c0:35:f7:15:64:f5 e5:9e:99:c6:c0:ee:25:82:f6:d5:9a:e8:b0:44:a6:44 36:34:5a:6d:ea:e3:49:fa:53:9e:2c:28:37:1c:e5:b2 40:68:85:12:76:6e:b0:b6:36:24:c9:9a:b4:31:2a:69 11:19:ae:ce:dc:d0:d2:da:e9:f6:3a:b8:74:09:20:6d 1b:23:68:8b:ed:b5:bd:2d:65:e3:79:b2:1b:63:1a:71 5c:2c:1f:2f:99:3c:71:de:80:e6:15:37:8a:56:d3:7f c3:06:c7:e3:f8:d5:3a:fb:08:e7:fc:b0:66:b8:37:21 e6:62:ac:11:b8:08:de:30:88:b8:c2:1e:42:76:c7:e8 a0:43:d6:29:10:79:06:f2:a3:4c:7f:45:a3:2a:e1:14 5c:dc:59:a3:e4:a2:7b:2a:ed:43:98:e3:61:21:d2:45 56:56:7d:36:71:28:21:7c:e2:46:bf:e6:a0:63:68:91 Exponent: 01:00:01 Extensions: Subject Key Identifier (not critical): e606b5edc8097e47e2b007b046f7f25aec75aa7a Authority Key Identifier (not critical): e606b5edc8097e47e2b007b046f7f25aec75aa7a Basic Constraints (not critical): Certificate Authority (CA): TRUE Signature Algorithm: RSA-SHA Signature: 26:2a:29:85:86:91:f4:47:1d:2f:78:72:80:12:3c:46 d5:54:2b:7e:19:fb:48:41:9c:f7:b0:56:91:54:24:9b 4e:21:16:b7:cc:0d:10:96:7c:71:50:71:69:21:0f:d8 11:d7:c6:c1:81:e3:70:b8:c8:a2:07:3a:30:6b:73:58 c1:13:bc:03:60:2b:c9:d3:9c:dd:62:3b:31:e1:83:24 a5:1d:c8:b8:38:26:56:69:32:a5:37:66:bc:4c:eb:bf 4f:9b:be:38:d0:0f:3c:08:68:a9:b6:98:1c:e8:90:77 3a:2f:c4:e6:b6:d8:1b:af:fc:76:55:f7:ac:61:26:32 a3:35:2f:c1:1d:56:d7:4f:3c:4b:6f:8d:24:ed:83:91 1d:0c:84:60:b5:df:3c:37:e6:bf:09:0f:ff:ef:a0:ac 0f:d4:31:59:1a:83:28:35:0d:b0:de:dc:89:dd:04:c4 1f:36:86:5f:12:96:7b:68:0b:9f:1c:ac:37:21:09:2f 93:b1:d7:f7:ed:03:81:8d:0e:93:21:57:c1:f8:a2:0b 27:d7:6d:0b:89:1b:f7:48:32:e8:fd:74:b3:3a:39:44 56:46:aa:d6:0b:84:1a:99:cb:57:ea:d6:ca:4f:e4:f5 b8:a4:df:68:ec:6f:03:f7:d1:0e:dc:93:04:c2:d5:31 Other Information: MD5 fingerprint: 1a935762dc457cc04f73decf99bf7d68 SHA-1 fingerprint: dca59469e5d8584b806f8864db4c819c31c58a7c Public Key Id: 56f3a855d567df5da964ec3d5bc1761471dd26fa -----BEGIN CERTIFICATE----- MIID9zCCAt+gAwIBAgIJAKHDykeyqBukMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNV BAYTAklOMRMwEQYDVQQIEwpTb21lLVN0YXRlMSEwHwYDVQQKExhJbnRlcm5ldCBX aWRnaXRzIFB0eSBMdGQxEzARBgNVBAMTCkFlcm9mbGV4Q0EwHhcNMDcxMDA4MDYw MTA0WhcNMDgxMDA3MDYwMTA0WjBaMQswCQYDVQQGEwJJTjETMBEGA1UECBMKU29t ZS1TdGF0ZTEhMB8GA1UEChMYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMRMwEQYD VQQDEwpBZXJvZmxleENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA v8g/dzfWBkAr5G+Aowde9U3myNGwjQx0JxiM0sEYYxmsAC/JLTLeNeXNgJd/X5Cx 0JiEoESWmIMi8KwEXqb6RmJjetal0k3f0ubANfcVZPXlnpnGwO4lgvbVmuiwRKZE NjRaberjSfpTniwoNxzlskBohRJ2brC2NiTJmrQxKmkRGa7O3NDS2un2Orh0CSBt GyNoi+21vS1l43myG2MacVwsHy+ZPHHegOYVN4pW03/DBsfj+NU6+wjn/LBmuDch 5mKsEbgI3jCIuMIeQnbH6KBD1ikQeQbyo0x/RaMq4RRc3Fmj5KJ7Ku1DmONhIdJF VlZ9NnEoIXziRr/moGNokQIDAQABo4G/MIG8MB0GA1UdDgQWBBTmBrXtyAl+R+Kw B7BG9/Ja7HWqejCBjAYDVR0jBIGEMIGBgBTmBrXtyAl+R+KwB7BG9/Ja7HWqeqFe pFwwWjELMAkGA1UEBhMCSU4xEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoT GEludGVybmV0IFdpZGdpdHMgUHR5IEx0ZDETMBEGA1UEAxMKQWVyb2ZsZXhDQYIJ AKHDykeyqBukMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADggEBACYqKYWG kfRHHS94coASPEbVVCt+GftIQZz3sFaRVCSbTiEWt8wNEJZ8cVBxaSEP2BHXxsGB 43C4yKIHOjBrc1jBE7wDYCvJ05zdYjsx4YMkpR3IuDgmVmkypTdmvEzrv0+bvjjQ DzwIaKm2mBzokHc6L8Tmttgbr/x2VfesYSYyozUvwR1W1088S2+NJO2DkR0MhGC1 3zw35r8JD//voKwP1DFZGoMoNQ2w3tyJ3QTEHzaGXxKWe2gLnxysNyEJL5Ox1/ft A4GNDpMhV8H4ogsn120LiRv3SDLo/XSzOjlEVkaq1guEGpnLV+rWyk/k9bik32js bwP30Q7ckwTC1TE= -----END CERTIFICATE----- C:\Program Files\GnuTLS-1.7.8\bin>certtool -i --infile cacert.pem X.509 Certificate Information: Version: 3 Serial Number (hex): 00a1c3ca47b2a81ba4 Issuer: C=IN,ST=Some-State,O=Internet Widgits Pty Ltd,CN=AeroflexCA Validity: Not Before: Mon Oct 06:01:04 UTC 2007 Not After: Tue Oct 06:01:04 UTC 2008 Subject: C=IN,ST=Some-State,O=Internet Widgits Pty Ltd,CN=AeroflexCA Subject Public Key Algorithm: RSA Modulus (bits 2048): bf:c8:3f:77:37:d6:06:40:2b:e4:6f:80:a3:07:5e:f5 4d:e6:c8:d1:b0:8d:0c:74:27:18:8c:d2:c1:18:63:19 ac:00:2f:c9:2d:32:de:35:e5:cd:80:97:7f:5f:90:b1 d0:98:84:a0:44:96:98:83:22:f0:ac:04:5e:a6:fa:46 62:63:7a:d6:a5:d2:4d:df:d2:e6:c0:35:f7:15:64:f5 e5:9e:99:c6:c0:ee:25:82:f6:d5:9a:e8:b0:44:a6:44 36:34:5a:6d:ea:e3:49:fa:53:9e:2c:28:37:1c:e5:b2 40:68:85:12:76:6e:b0:b6:36:24:c9:9a:b4:31:2a:69 11:19:ae:ce:dc:d0:d2:da:e9:f6:3a:b8:74:09:20:6d 1b:23:68:8b:ed:b5:bd:2d:65:e3:79:b2:1b:63:1a:71 5c:2c:1f:2f:99:3c:71:de:80:e6:15:37:8a:56:d3:7f c3:06:c7:e3:f8:d5:3a:fb:08:e7:fc:b0:66:b8:37:21 e6:62:ac:11:b8:08:de:30:88:b8:c2:1e:42:76:c7:e8 a0:43:d6:29:10:79:06:f2:a3:4c:7f:45:a3:2a:e1:14 5c:dc:59:a3:e4:a2:7b:2a:ed:43:98:e3:61:21:d2:45 56:56:7d:36:71:28:21:7c:e2:46:bf:e6:a0:63:68:91 Exponent: 01:00:01 Extensions: Subject Key Identifier (not critical): e606b5edc8097e47e2b007b046f7f25aec75aa7a Authority Key Identifier (not critical): e606b5edc8097e47e2b007b046f7f25aec75aa7a Basic Constraints (not critical): Certificate Authority (CA): TRUE Signature Algorithm: RSA-SHA Signature: 26:2a:29:85:86:91:f4:47:1d:2f:78:72:80:12:3c:46 d5:54:2b:7e:19:fb:48:41:9c:f7:b0:56:91:54:24:9b 4e:21:16:b7:cc:0d:10:96:7c:71:50:71:69:21:0f:d8 11:d7:c6:c1:81:e3:70:b8:c8:a2:07:3a:30:6b:73:58 c1:13:bc:03:60:2b:c9:d3:9c:dd:62:3b:31:e1:83:24 a5:1d:c8:b8:38:26:56:69:32:a5:37:66:bc:4c:eb:bf 4f:9b:be:38:d0:0f:3c:08:68:a9:b6:98:1c:e8:90:77 3a:2f:c4:e6:b6:d8:1b:af:fc:76:55:f7:ac:61:26:32 a3:35:2f:c1:1d:56:d7:4f:3c:4b:6f:8d:24:ed:83:91 1d:0c:84:60:b5:df:3c:37:e6:bf:09:0f:ff:ef:a0:ac 0f:d4:31:59:1a:83:28:35:0d:b0:de:dc:89:dd:04:c4 1f:36:86:5f:12:96:7b:68:0b:9f:1c:ac:37:21:09:2f 93:b1:d7:f7:ed:03:81:8d:0e:93:21:57:c1:f8:a2:0b 27:d7:6d:0b:89:1b:f7:48:32:e8:fd:74:b3:3a:39:44 56:46:aa:d6:0b:84:1a:99:cb:57:ea:d6:ca:4f:e4:f5 b8:a4:df:68:ec:6f:03:f7:d1:0e:dc:93:04:c2:d5:31 Other Information: MD5 fingerprint: 1a935762dc457cc04f73decf99bf7d68 SHA-1 fingerprint: dca59469e5d8584b806f8864db4c819c31c58a7c Public Key Id: 56f3a855d567df5da964ec3d5bc1761471dd26fa -----BEGIN CERTIFICATE----- MIID9zCCAt+gAwIBAgIJAKHDykeyqBukMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNV BAYTAklOMRMwEQYDVQQIEwpTb21lLVN0YXRlMSEwHwYDVQQKExhJbnRlcm5ldCBX aWRnaXRzIFB0eSBMdGQxEzARBgNVBAMTCkFlcm9mbGV4Q0EwHhcNMDcxMDA4MDYw MTA0WhcNMDgxMDA3MDYwMTA0WjBaMQswCQYDVQQGEwJJTjETMBEGA1UECBMKU29t ZS1TdGF0ZTEhMB8GA1UEChMYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMRMwEQYD VQQDEwpBZXJvZmxleENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA v8g/dzfWBkAr5G+Aowde9U3myNGwjQx0JxiM0sEYYxmsAC/JLTLeNeXNgJd/X5Cx 0JiEoESWmIMi8KwEXqb6RmJjetal0k3f0ubANfcVZPXlnpnGwO4lgvbVmuiwRKZE NjRaberjSfpTniwoNxzlskBohRJ2brC2NiTJmrQxKmkRGa7O3NDS2un2Orh0CSBt GyNoi+21vS1l43myG2MacVwsHy+ZPHHegOYVN4pW03/DBsfj+NU6+wjn/LBmuDch 5mKsEbgI3jCIuMIeQnbH6KBD1ikQeQbyo0x/RaMq4RRc3Fmj5KJ7Ku1DmONhIdJF VlZ9NnEoIXziRr/moGNokQIDAQABo4G/MIG8MB0GA1UdDgQWBBTmBrXtyAl+R+Kw B7BG9/Ja7HWqejCBjAYDVR0jBIGEMIGBgBTmBrXtyAl+R+KwB7BG9/Ja7HWqeqFe pFwwWjELMAkGA1UEBhMCSU4xEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoT GEludGVybmV0IFdpZGdpdHMgUHR5IEx0ZDETMBEGA1UEAxMKQWVyb2ZsZXhDQYIJ AKHDykeyqBukMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADggEBACYqKYWG kfRHHS94coASPEbVVCt+GftIQZz3sFaRVCSbTiEWt8wNEJZ8cVBxaSEP2BHXxsGB 43C4yKIHOjBrc1jBE7wDYCvJ05zdYjsx4YMkpR3IuDgmVmkypTdmvEzrv0+bvjjQ DzwIaKm2mBzokHc6L8Tmttgbr/x2VfesYSYyozUvwR1W1088S2+NJO2DkR0MhGC1 3zw35r8JD//voKwP1DFZGoMoNQ2w3tyJ3QTEHzaGXxKWe2gLnxysNyEJL5Ox1/ft A4GNDpMhV8H4ogsn120LiRv3SDLo/XSzOjlEVkaq1guEGpnLV+rWyk/k9bik32js bwP30Q7ckwTC1TE= -----END CERTIFICATE----- C:\Program Files\GnuTLS-1.7.8\bin>certtool -i --infile server-cert.pem X.509 Certificate Information: Version: 3 Serial Number (hex): 100002 Issuer: C=IN,ST=Some-State,O=Internet Widgits Pty Ltd,CN=AeroflexCA Validity: Not Before: Mon Oct 06:04:59 UTC 2007 Not After: Tue Oct 06:04:59 UTC 2008 Subject: C=IN,ST=Some-State,O=Internet Widgits Pty Ltd,CN=172.21.111.70 Subject Public Key Algorithm: RSA Modulus (bits 2048): c9:2f:29:c4:88:0b:28:dd:7d:29:ec:e9:2f:e2:14:a0 49:aa:e3:c2:a6:b5:63:57:f6:76:71:10:f8:8f:ab:49 63:64:1c:50:70:3a:e6:9a:87:47:5f:75:77:1b:2c:43 76:a1:db:f4:05:89:61:d7:d0:8b:23:4e:d0:9f:43:36 83:4c:3e:0f:5c:82:a6:eb:5e:a3:90:3e:7c:e1:29:4c 7b:4e:72:36:ad:27:0e:98:8a:2c:cc:69:76:63:d6:00 75:03:95:01:83:b9:56:0b:89:a0:fc:d1:ac:86:74:52 8f:84:58:a8:54:b2:b4:2b:24:65:8f:d0:5a:78:4b:c1 e2:f8:c3:0e:7e:ed:2e:ed:aa:cd:3a:b5:ec:5e:c0:86 0d:f8:d6:7d:da:e7:93:73:25:aa:da:8b:c0:6d:36:7e cc:fb:35:01:27:9a:ff:55:23:b9:70:83:83:af:44:af a6:63:cc:2b:47:d4:9c:71:92:ad:f1:32:b4:a8:bc:91 b2:9d:d4:2e:ac:91:c4:82:39:83:79:6f:28:a5:fc:8a 7f:8e:44:2d:7b:f9:c7:9c:31:0a:5d:72:01:e9:fa:69 fc:f6:47:0e:f7:9c:67:de:39:71:37:28:8d:7e:fd:61 c4:6c:c5:12:ed:ce:38:0c:dc:b6:35:d3:43:12:54:ab Exponent: 01:00:01 Extensions: Basic Constraints (not critical): Certificate Authority (CA): FALSE Unknown extension 2.16.840.1.113730.1.13 (not critical): ASCII: ..OpenSSL Generated Certificate Hexdump: 161d4f70656e53534c2047656e657261746564204365727 469666963617465 Subject Key Identifier (not critical): ffdf1eb5a22a1278d28193b11ea6dd3d4500e331 Authority Key Identifier (not critical): e606b5edc8097e47e2b007b046f7f25aec75aa7a Signature Algorithm: RSA-SHA Signature: 8b:22:70:d4:c2:b5:3d:5d:7c:f3:b6:c5:69:6a:09:fd 2f:ee:1a:7c:43:0e:b6:37:df:c0:98:e0:2c:5b:26:58 be:19:33:35:47:45:81:68:cc:61:be:8f:15:aa:af:fa f2:1d:5e:6a:05:83:0b:5a:2a:e6:82:c1:22:8f:ba:c0 c1:b5:ea:f4:30:14:de:3a:8c:d6:bd:00:fb:68:c5:49 9a:e6:30:86:ad:69:e0:21:74:06:1e:35:06:a7:e9:56 a1:ea:53:da:c0:4b:dc:52:13:02:1a:32:8f:44:43:8c 9b:d2:01:98:93:40:f9:64:4d:33:39:51:32:3c:53:ba 44:05:2e:c6:d0:6f:61:a1:22:0b:07:f2:5e:4e:bb:25 4f:b7:d1:3f:b1:81:f1:8b:ce:27:6a:8f:cc:44:5b:4d aa:0c:de:cf:e2:6d:d4:d7:8d:a7:e7:1d:89:f4:f7:1c a8:b0:62:3a:ca:89:b4:57:5d:10:4a:77:8e:c1:95:42 ed:35:7a:60:e5:28:76:80:b0:41:c6:c7:9e:3f:93:bc 1c:29:f1:e1:77:b7:0c:98:39:18:97:54:7b:f1:18:cf bb:bc:71:05:12:3f:6b:14:03:21:b5:37:2d:86:ff:68 c2:eb:24:76:0c:5a:a5:1d:b0:f1:ea:ca:78:63:bd:01 Other Information: MD5 fingerprint: 61c03dbffa8473dae73d504f22251422 SHA-1 fingerprint: 440551975e43a330f9d48369cf9bc2537201f997 Public Key Id: d7736969149efc3938c733ac20b01d953039f443 -----BEGIN CERTIFICATE----- MIIDrzCCApegAwIBAgIDEAACMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAklO MRMwEQYDVQQIEwpTb21lLVN0YXRlMSEwHwYDVQQKExhJbnRlcm5ldCBXaWRnaXRz IFB0eSBMdGQxEzARBgNVBAMTCkFlcm9mbGV4Q0EwHhcNMDcxMDA4MDYwNDU5WhcN MDgxMDA3MDYwNDU5WjBdMQswCQYDVQQGEwJJTjETMBEGA1UECBMKU29tZS1TdGF0 ZTEhMB8GA1UEChMYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMRYwFAYDVQQDEw0x NzIuMjEuMTExLjcwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyS8p xIgLKN19KezpL+IUoEmq48KmtWNX9nZxEPiPq0ljZBxQcDrmmodHX3V3GyxDdqHb 9AWJYdfQiyNO0J9DNoNMPg9cgqbrXqOQPnzhKUx7TnI2rScOmIoszGl2Y9YAdQOV AYO5VguJoPzRrIZ0Uo+EWKhUsrQrJGWP0Fp4S8Hi+MMOfu0u7arNOrXsXsCGDfjW fdrnk3MlqtqLwG02fsz7NQEnmv9VI7lwg4OvRK+mY8wrR9SccZKt8TK0qLyRsp3U LqyRxII5g3lvKKX8in+ORC17+cecMQpdcgHp+mn89kcO95xn3jlxNyiNfv1hxGzF Eu3OOAzctjXTQxJUqwIDAQABo3sweTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU/98etaIq EnjSgZOxHqbdPUUA4zEwHwYDVR0jBBgwFoAU5ga17cgJfkfisAewRvfyWux1qnow DQYJKoZIhvcNAQEFBQADggEBAIsicNTCtT1dfPO2xWlqCf0v7hp8Qw62N9/AmOAs WyZYvhkzNUdFgWjMYb6PFaqv+vIdXmoFgwtaKuaCwSKPusDBter0MBTeOozWvQD7 aMVJmuYwhq1p4CF0Bh41BqfpVqHqU9rAS9xSEwIaMo9EQ4yb0gGYk0D5ZE0zOVEy PFO6RAUuxtBvYaEiCwfyXk67JU+30T+xgfGLzidqj8xEW02qDN7P4m3U142n5x2J 9PccqLBiOsqJtFddEEp3jsGVQu01emDlKHaAsEHGx54/k7wcKfHhd7cMmDkYl1R7 8RjPu7xxBRI/axQDIbU3LYb/aMLrJHYMWqUdsPHqynhjvQE= -----END CERTIFICATE----- Regards, Rajeev Saini ____________________________________________ Experience certainty. IT Services Business Solutions Outsourcing ____________________________________________ Nikos Mavrogiannopoulos Sent by: Nikos Mavrogiannopoulos 10/08/2007 04:28 PM To help-gnutls at gnu.org cc Rajeev Saini Subject Re: [Help-gnutls] Windows GnuTLS problem in handshaking. On Monday 08 October 2007, Rajeev Saini wrote: > Hi, > I have managed to make DER encoded certificate and named it SuplRootCert > and put it in the mobile(client). > My server uses cacert.pem, server-cert.pem and server-key.pem to run the > server. All these certificates were nade using openssl. > Now when both interacts and does handshaking, i am getting the following > error message. Please send the output of certtool -i of the certificates and the client certificate that cause problem. regards, Nikos ForwardSourceID:NT000064AA =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon Oct 8 15:10:45 2007 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 8 Oct 2007 16:10:45 +0300 Subject: [Help-gnutls] Windows GnuTLS problem in handshaking. In-Reply-To: References: Message-ID: <200710081610.45989.nmav@gnutls.org> On Monday 08 October 2007, you wrote: > C:\Program Files\GnuTLS-1.7.8\bin>certtool -i --inder --infile It seems you are using different version of certtool and gnutls-serv to read this certificate. Does the latest version of gnutls works for you? I have no problem to parse this certificate with the latest code. regards, Nikos From simon at josefsson.org Mon Oct 8 16:08:54 2007 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 08 Oct 2007 16:08:54 +0200 Subject: [Help-gnutls] Re: [PATCH] fix gnutls guile detection In-Reply-To: <874phbfikv.fsf@hades.wkstn.nix> (nix@esperi.org.uk's message of "Mon, 01 Oct 2007 07:35:28 +0100") References: <874phbfikv.fsf@hades.wkstn.nix> Message-ID: <87ir5hn1ft.fsf@mocca.josefsson.org> Nix writes: > (I tried to send this to gnutls-dev@, but it doesn't allow posts from > non-subscribers, and a fly-by-night patch such as this doesn't merit > subscription.) I'm using help-gnutls at gnu.org now, I believe it accept such posts. We should probably move gnutls-dev to gnu.org since their mailman configuration seems slightly better in a few places. > The configure script is substituting GUILE_LDFLAGS into LDFLAGS, when > it's not an LDFLAGS replacement, it's a LIBS replacement. If you put it > into LDFLAGS, you're likely to end up with a command line the moral > equivalent of > > gcc -lguile -o conftest conftest.c > > which of course will fail to pick up references in conftest.c. > > We can't really rename GUILE_LDFLAGS here because it's part of guile, > but we can certainly fix its use in the configure script. > > This trivial patch applies against both the gnutls_2_0_x branch and the head. Ludovic, I can't judge this. Can you take a look? Feel free to check your commit access by installing (together with a NEWS entry). :) It should probably go into the 2.0.x branch as well? /Simon > 2007-09-29 Nix > > * configure.in: Substitute GUILE_LDFLAGS into LIBS, not LDFLAGS. > > Index: 2.0.1/configure.in > =================================================================== > --- 2.0.1.orig/configure.in 2007-09-17 10:13:36.000000000 +0100 > +++ 2.0.1/configure.in 2007-09-29 12:45:27.000000000 +0100 > @@ -312,14 +312,14 @@ > GUILE_FLAGS > > save_CFLAGS="$CFLAGS" > - save_LDFLAGS="$LDFLAGS" > + save_LIBS="$LIBS" > CFLAGS="$CFLAGS $GUILE_CFLAGS" > - LDFLAGS="$LDFLAGS $GUILE_LDFLAGS" > + LIBS="$LIBS $GUILE_LDFLAGS" > AC_MSG_CHECKING([whether GNU Guile is recent enough]) > AC_LINK_IFELSE(AC_LANG_CALL([], [scm_from_locale_string]), > [], [opt_guile_bindings=no]) > CFLAGS="$save_CFLAGS" > - LDFLAGS="$save_LDFLAGS" > + LIBS="$save_LIBS" > > if test "x$opt_guile_bindings" = "xyes"; then > AC_MSG_RESULT([yes]) From nmav at gnutls.org Tue Oct 9 00:53:05 2007 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 9 Oct 2007 01:53:05 +0300 Subject: [Help-gnutls] Windows GnuTLS problem in handshaking. In-Reply-To: References: Message-ID: <200710090153.05870.nmav@gnutls.org> On Monday 08 October 2007, Rajeev Saini wrote: Are you sure the client sends the certificate correctly? As far as I can see from the dump (below) the certificate packet sent by the client contains 10 bytes only (not really a certificate). What it the client program you are using? Ok... I've translated those bytes to TLS protocol and it seems that this client is sending "00 00 03 00 00 00" as the certificate (he means empty certificate). The normal way to send it is to send "00 00 00". The one above confuses as it seems gnutls. Does the attached patch solve this problem to you? > |<3>| HSK[ac08a8]: CERTIFICATE was received [10 bytes] > |<6>| BUF[REC][HD]: Read 6 bytes of Data(22) > |<6>| BUF[HSK]: Peeked 0 bytes of Data > |<6>| BUF[HSK]: Emptied buffer > |<6>| BUF[HSK]: Inserted 4 bytes of Data > |<6>| BUF[HSK]: Inserted 6 bytes of Data > |<2>| ASSERT: ../../../../src/gnutls-2.0.0/lib/x509/x509.c:219 > |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/gnutls_cert.c:758 > |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/auth_cert.c:932 > |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/gnutls_kx.c:612 > |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/gnutls_handshake.c:2568 > |<6>| BUF[HSK]: Cleared Data from buffer > > Error in handshake > Error: ASN1 parser: Error in TAG. > > |<4>| REC: Sending Alert[2|42] - Certificate is bad -------------- next part -------------- diff --git a/lib/auth_cert.c b/lib/auth_cert.c index 54b4a50..a25b753 100644 --- a/lib/auth_cert.c +++ b/lib/auth_cert.c @@ -869,7 +869,10 @@ _gnutls_proc_x509_server_certificate (gnutls_session_t session, size = _gnutls_read_uint24 (p); p += 3; - if (size == 0) + /* some implementations send 00 00 03 00 00 00 + * instead of just 00 00 00. + */ + if (size == 0 || size == 3) { gnutls_assert (); /* no certificate was sent */ From preeti.shandilya at aricent.com Tue Oct 9 10:42:29 2007 From: preeti.shandilya at aricent.com (Preeti Shandilya) Date: Tue, 9 Oct 2007 14:12:29 +0530 Subject: [Help-gnutls] (no subject) Message-ID: Hi ! Can somebody tell me if GNU TLS is available on VxWorks platform regards Preeti *********************** Aricent-Unclassified *********************** "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.saini at tcs.com Tue Oct 9 10:05:29 2007 From: rajeev.saini at tcs.com (Rajeev Saini) Date: Tue, 9 Oct 2007 13:35:29 +0530 Subject: [Help-gnutls] Windows GnuTLS problem in handshaking. In-Reply-To: <200710090153.05870.nmav@gnutls.org> Message-ID: Hi Nikos, Thanks for your response. My client is a Qualcomm 6280 UMTS mobile and i am provisioning the certificate into it using the attached document. Now if we see the command to provision the certificate on the mobile Command used:- Step6: openssl x509 ?in cacert.pem ?out SuplRootCert ?inform PEM ?outform DER It seems that we are converting the CA certificate to DER format and naming it SuplRootCert and loaded it into the mobile. This is somewhat saying that we are putting CA public key into the mobile. Therefore it seems when the step comes such that mobile has to send its certificate, it will send an empty certificate, since it does not have a client certificate. We are only told that the certificate should be of the name SuplRootCert and should be in a particular folder of a mobile. My understanding so far is that mobile should have both the CA public key and client Certificate onto it to run properly. Regards, Rajeev Saini Nikos Mavrogiannopoulos Sent by: Nikos Mavrogiannopoulos 10/09/2007 04:23 AM To help-gnutls at gnu.org cc Rajeev Saini Subject Re: [Help-gnutls] Windows GnuTLS problem in handshaking. On Monday 08 October 2007, Rajeev Saini wrote: Are you sure the client sends the certificate correctly? As far as I can see from the dump (below) the certificate packet sent by the client contains 10 bytes only (not really a certificate). What it the client program you are using? Ok... I've translated those bytes to TLS protocol and it seems that this client is sending "00 00 03 00 00 00" as the certificate (he means empty certificate). The normal way to send it is to send "00 00 00". The one above confuses as it seems gnutls. Does the attached patch solve this problem to you? > |<3>| HSK[ac08a8]: CERTIFICATE was received [10 bytes] > |<6>| BUF[REC][HD]: Read 6 bytes of Data(22) > |<6>| BUF[HSK]: Peeked 0 bytes of Data > |<6>| BUF[HSK]: Emptied buffer > |<6>| BUF[HSK]: Inserted 4 bytes of Data > |<6>| BUF[HSK]: Inserted 6 bytes of Data > |<2>| ASSERT: ../../../../src/gnutls-2.0.0/lib/x509/x509.c:219 > |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/gnutls_cert.c:758 > |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/auth_cert.c:932 > |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/gnutls_kx.c:612 > |<2>| ASSERT: ../../../src/gnutls-2.0.0/lib/gnutls_handshake.c:2568 > |<6>| BUF[HSK]: Cleared Data from buffer > > Error in handshake > Error: ASN1 parser: Error in TAG. > > |<4>| REC: Sending Alert[2|42] - Certificate is bad ForwardSourceID:NT000064D2 =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Generate SSL certs .doc Type: application/octet-stream Size: 29184 bytes Desc: not available URL: From simon at josefsson.org Tue Oct 9 16:25:36 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 09 Oct 2007 16:25:36 +0200 Subject: [Help-gnutls] Re: (no subject) In-Reply-To: (Preeti Shandilya's message of "Tue, 9 Oct 2007 14:12:29 +0530") References: Message-ID: <87y7ec8ivz.fsf@mocca.josefsson.org> Preeti Shandilya writes: > Hi ! > > Can somebody tell me if GNU TLS is available on VxWorks platform Hi, and thanks for your interest. Nobody has built GnuTLS on VxWorks that I know of. However, I think there is some (limited) support for VxWorks in gcc, autoconf and libtool. So try following the standard build instructions. Start with libgpg-error and run ./configure + make install etc. Btw, if you want someone to spend time working on VxWorks, consider commercial support: http://www.gnu.org/software/gnutls/commercial.html /Simon From simon at josefsson.org Tue Oct 9 16:30:21 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 09 Oct 2007 16:30:21 +0200 Subject: [Help-gnutls] Re: Windows GnuTLS problem in handshaking. In-Reply-To: <200710090153.05870.nmav@gnutls.org> (Nikos Mavrogiannopoulos's message of "Tue, 9 Oct 2007 01:53:05 +0300") References: <200710090153.05870.nmav@gnutls.org> Message-ID: <87tzp08io2.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > On Monday 08 October 2007, Rajeev Saini wrote: > > Are you sure the client sends the certificate correctly? As far as I can see > from the dump (below) the certificate packet sent by the client contains 10 > bytes only (not really a certificate). What it the client program you are > using? > > Ok... I've translated those bytes to TLS protocol and it seems that this > client is sending "00 00 03 00 00 00" as the certificate (he means empty > certificate). > > The normal way to send it is to send "00 00 00". The one above confuses as it > seems gnutls. Does the attached patch solve this problem to you? Supporting this may be needed, although I think we should add a gnutls_assert or similar to make sure it can be noticed during debugging. The TLS 1.2 has some wording to make it explicit that the _list_ should be empty rather than having an empty certificate in the list. It would be great if we can confirm that the patch solves the problem. /Simon From simon at josefsson.org Tue Oct 9 17:04:08 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 09 Oct 2007 17:04:08 +0200 Subject: [Help-gnutls] Re: Windows GnuTLS problem in handshaking. In-Reply-To: <87tzp08io2.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 09 Oct 2007 16:30:21 +0200") References: <200710090153.05870.nmav@gnutls.org> <87tzp08io2.fsf@mocca.josefsson.org> Message-ID: <87hcl08h3r.fsf@mocca.josefsson.org> Simon Josefsson writes: > Nikos Mavrogiannopoulos writes: > >> On Monday 08 October 2007, Rajeev Saini wrote: >> >> Are you sure the client sends the certificate correctly? As far as I can see >> from the dump (below) the certificate packet sent by the client contains 10 >> bytes only (not really a certificate). What it the client program you are >> using? >> >> Ok... I've translated those bytes to TLS protocol and it seems that this >> client is sending "00 00 03 00 00 00" as the certificate (he means empty >> certificate). >> >> The normal way to send it is to send "00 00 00". The one above confuses as it >> seems gnutls. Does the attached patch solve this problem to you? > > Supporting this may be needed, although I think we should add a > gnutls_assert or similar to make sure it can be noticed during > debugging. The TLS 1.2 has some wording to make it explicit that the > _list_ should be empty rather than having an empty certificate in the > list. I just noticed there already was a gnutls_assert in that code... so already taken care of. /Simon From ludo at gnu.org Mon Oct 8 23:40:57 2007 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Mon, 08 Oct 2007 23:40:57 +0200 Subject: [Help-gnutls] Re: [PATCH] fix gnutls guile detection References: <874phbfikv.fsf@hades.wkstn.nix> <87ir5hn1ft.fsf@mocca.josefsson.org> Message-ID: <87d4vp8ety.fsf@chbouib.org> Hi, Simon Josefsson writes: > Ludovic, I can't judge this. Can you take a look? Feel free to check > your commit access by installing (together with a NEWS entry). :) It > should probably go into the 2.0.x branch as well? I successfully committed the fix both to `master' and `gnutls_2_0_x' (I used `git-cherry-pick' to copy the patches from the former to the latter). :-) Thanks! Ludo'. From kristian.martens at freenet.de Thu Oct 11 15:23:34 2007 From: kristian.martens at freenet.de (kristian.martens at freenet.de) Date: Thu, 11 Oct 2007 15:23:34 +0200 Subject: [Help-gnutls] High Load Message-ID: Hi, I am using the GNUTLS lib with PSK authentication with 1000s of subscribers.. Each single authentication runs in an own client and server task (that means 2 - 50 authentications can run in parallel). Sometimes the following output is seen in the log: "Assertion failed: *lock == MUTEX_UNLOCKED, file ath.c, line 188" After that the task hangs and cannot be used anymore. This phenomenon shows sporadically. Does anybody have the same experience? Any idea what leads to that problem? Thanks, Kris From nmav at gnutls.org Thu Oct 11 17:19:55 2007 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 11 Oct 2007 18:19:55 +0300 Subject: [Help-gnutls] High Load In-Reply-To: References: Message-ID: <200710111819.56178.nmav@gnutls.org> On Thursday 11 October 2007, kristian.martens at freenet.de wrote: > Hi, > > I am using the GNUTLS lib with PSK authentication with 1000s of > subscribers.. Each single authentication runs in an own client and server > task (that means 2 - 50 authentications can run in parallel). Sometimes the > following output is seen in the log: > "Assertion failed: *lock == MUTEX_UNLOCKED, file ath.c, line 188" What do you mean by task? Do you mean threads? If yes then you have to check http://www.gnu.org/software/gnutls/manual/html_node/Multi_002dthreaded-applications.html#Multi_002dthreaded-applications Otherwise please provide more information on how you use gnutls (fork, when do you call global_init etc.) regards, Nikos From simon at josefsson.org Fri Oct 12 15:36:15 2007 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 12 Oct 2007 15:36:15 +0200 Subject: [Help-gnutls] Re: [PATCH] fix gnutls guile detection In-Reply-To: <87d4vp8ety.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?= =?iso-8859-1?Q?=E8s=22's?= message of "Mon, 08 Oct 2007 23:40:57 +0200") References: <874phbfikv.fsf@hades.wkstn.nix> <87ir5hn1ft.fsf@mocca.josefsson.org> <87d4vp8ety.fsf@chbouib.org> Message-ID: <877ilsxxo0.fsf@mocca.josefsson.org> ludo at gnu.org (Ludovic Court?s) writes: > Hi, > > Simon Josefsson writes: > >> Ludovic, I can't judge this. Can you take a look? Feel free to check >> your commit access by installing (together with a NEWS entry). :) It >> should probably go into the 2.0.x branch as well? > > I successfully committed the fix both to `master' and `gnutls_2_0_x' (I > used `git-cherry-pick' to copy the patches from the former to the > latter). :-) Visible from here, so I reckon it worked. Thanks! /Simon From Kip at TheVertigo.com Fri Oct 12 21:32:17 2007 From: Kip at TheVertigo.com (Kip Warner) Date: Fri, 12 Oct 2007 12:32:17 -0700 (PDT) Subject: [Help-gnutls] Beginner Questions Message-ID: <13177782.post@talk.nabble.com> Greetings, I am new to GnuTLS and I am slowly learning more about cryptography in general. I would like to build both a client and server application, with the following security constraints: - The server needn't authenticate the client because it doesn't care who it is. - The client, however, needs to be sure that the server it connected to really is the genuine server and not an impostor. The IP address of the server machine may change from time to time (it is on DHCP), but the server machine itself will always be the same. It will be identified by hostname. - The communication between the two should be encrypted and sent over the wire via TLS 1.1. The protocol the two will use will be my own text based protocol handled through gnutls_record_recv() / gnutls_record_send(). I am using the sample "Echo Server with OpenPGP Authentication" as a starting point for implementing the server. I just hope this is the right kind of basic skeleton model I should be using for pedagogical purposes. Do you think this is sufficient? http://www.gnu.org/software/gnutls/manual/html_node/Echo-Server-with-OpenPGP-authentication.html I have gone through some of the OpenSSL documentation and GnuTLS's documentation on certtool, but I am still confused on how to generate the three files mentioned at the beginning of the server's source. I cannot seem to find any mention of their creation anywhere. Could be that I am just looking in all the wrong places: #define KEYFILE "secret.asc" #define CERTFILE "public.asc" #define RINGFILE "ring.gpg" But just as importantly, what do each of these really mean (I kind of understand the public and secret files, but not really the keyring - but nevertheless, I do not feel confident in my understanding of any of the three). Also, where should these three files reside? What should the client have and what should the server have available to them on disk? Thank you for any guidance you can provide. -- Kip Warner Software Engineer http://www.thevertigo.com -- View this message in context: http://www.nabble.com/Beginner-Questions-tf4614419.html#a13177782 Sent from the Gnu - TLS mailing list archive at Nabble.com. From nmav at gnutls.org Fri Oct 12 21:50:15 2007 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 12 Oct 2007 22:50:15 +0300 Subject: [Help-gnutls] Beginner Questions In-Reply-To: <13177782.post@talk.nabble.com> References: <13177782.post@talk.nabble.com> Message-ID: <200710122250.15732.nmav@gnutls.org> On Friday 12 October 2007, Kip Warner wrote: > Greetings, > > I am new to GnuTLS and I am slowly learning more about cryptography in > general. I would like to build both a client and server application, > with the following security constraints: > - The server needn't authenticate the client because it doesn't care who > it is. > - The client, however, needs to be sure that the server it connected to > really is the genuine server and not an impostor. The IP address of the > server machine may change from time to time (it is on DHCP), but the > server machine itself will always be the same. It will be identified by > hostname. > - The communication between the two should be encrypted and sent over > the wire via TLS 1.1. > The protocol the two will use will be my own text based protocol handled > through gnutls_record_recv() / gnutls_record_send(). I am using the > sample "Echo Server with OpenPGP Authentication" as a starting point for > implementing the server. I just hope this is the right kind of basic > skeleton model I should be using for pedagogical purposes. Do you think > this is sufficient? Actually for pedagogical purposes I'd suggest to use an X.509 server. These are for sure well tested. However openpgp should work too but is not as well tested. > I have gone through some of the OpenSSL documentation and GnuTLS's > documentation on certtool, but I am still confused on how to generate > the three files mentioned at the beginning of the server's source. I > cannot seem to find any mention of their creation anywhere. Could be > that I am just looking in all the wrong places: > > #define KEYFILE "secret.asc" > #define CERTFILE "public.asc" Those two can be generated using gpg (gnupg) and exported without a password key for the key file. > #define RINGFILE "ring.gpg" This is a collection of pgp keys that will be used to verify the client's pgp key. If it is signed by at least one of these keys it will be considered trusted. Otherwise not. This file is also generated using gpg. You export using gpg --export key1 key2 etc... > three). Also, where should these three files reside? What should the > client have and what should the server have available to them on disk? Since you don't care about client authentication, the client should use the ring file and the server the two keys. You might want to help us improve the documentation by specifying the sections you didn't understand, or even by adding text that you consider helpful for you. regards, Nikos From Kip at TheVertigo.com Sat Oct 13 01:31:18 2007 From: Kip at TheVertigo.com (Kip Warner) Date: Fri, 12 Oct 2007 16:31:18 -0700 (PDT) Subject: [Help-gnutls] Beginner Questions In-Reply-To: <200710122250.15732.nmav@gnutls.org> References: <13177782.post@talk.nabble.com> <200710122250.15732.nmav@gnutls.org> Message-ID: <13184749.post@talk.nabble.com> Thanks Nikos. I have generated CERTFILE: gpg --gen-keys gpg --armor --export KEYID > public.asc ..and KEYFILE is generated with: gpg --armor --export-secret-keys KEYID > secret.asc ..and the RINGFILE is generated with: gpg --export KEYID > keyring.gpg When I try to connect to my server with... $ gnutls-cli -V -p 12345 --pgpkeyring keyring.gpg localhost I get... Resolving 'localhost'... Connecting to '127.0.0.1:59783'... *** Fatal error: Public key signature verification has failed. *** Handshake has failed GNUTLS ERROR: Public key signature verification has failed. Any ideas? Kip -- View this message in context: http://www.nabble.com/Beginner-Questions-tf4614419.html#a13184749 Sent from the Gnu - TLS mailing list archive at Nabble.com. From ludovic.courtes at laas.fr Mon Oct 15 11:14:52 2007 From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Mon, 15 Oct 2007 11:14:52 +0200 Subject: [Help-gnutls] Re: Beginner Questions References: <13177782.post@talk.nabble.com> <200710122250.15732.nmav@gnutls.org> <13184749.post@talk.nabble.com> Message-ID: <87fy0cyc1f.fsf@laas.fr> HI, Kip Warner writes: > When I try to connect to my server with... > $ gnutls-cli -V -p 12345 --pgpkeyring keyring.gpg localhost > > I get... > > Resolving 'localhost'... > Connecting to '127.0.0.1:59783'... > *** Fatal error: Public key signature verification has failed. > *** Handshake has failed > GNUTLS ERROR: Public key signature verification has failed. Which version of GnuTLS are you using? The 1.6 and early 1.7 series had problems with OpenPGP authentication IIRC. Besides, you may want to add debugging output (with, say, "-d 5") to get a better idea of what fails exactly. Hope this helps, Ludovic. From Kip at TheVertigo.com Tue Oct 16 00:21:31 2007 From: Kip at TheVertigo.com (Kip Warner) Date: Mon, 15 Oct 2007 15:21:31 -0700 (PDT) Subject: [Help-gnutls] Beginner Questions In-Reply-To: <87fy0cyc1f.fsf@laas.fr> References: <13177782.post@talk.nabble.com> <200710122250.15732.nmav@gnutls.org> <13184749.post@talk.nabble.com> <87fy0cyc1f.fsf@laas.fr> Message-ID: <13223250.post@talk.nabble.com> HI, Kip Warner writes: > When I try to connect to my server with... > $ gnutls-cli -V -p 12345 --pgpkeyring keyring.gpg localhost > > I get... > > Resolving 'localhost'... > Connecting to '127.0.0.1:59783'... > *** Fatal error: Public key signature verification has failed. > *** Handshake has failed > GNUTLS ERROR: Public key signature verification has failed. Which version of GnuTLS are you using? The 1.6 and early 1.7 series had problems with OpenPGP authentication IIRC. Besides, you may want to add debugging output (with, say, "-d 5") to get a better idea of what fails exactly. Hope this helps, Ludovic. I have heard that OpenPGP isn't quite up to par yet and still buggy. I will try the X.509 method and let you gentlemen know should anything unexpected popup. Thanks again. Kip -- View this message in context: http://www.nabble.com/Beginner-Questions-tf4614419.html#a13223250 Sent from the Gnu - TLS mailing list archive at Nabble.com. From ludovic.courtes at laas.fr Wed Oct 17 13:09:40 2007 From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Wed, 17 Oct 2007 13:09:40 +0200 Subject: [Help-gnutls] Re: Beginner Questions References: <13177782.post@talk.nabble.com> <200710122250.15732.nmav@gnutls.org> <13184749.post@talk.nabble.com> <87fy0cyc1f.fsf@laas.fr> <13223250.post@talk.nabble.com> Message-ID: <873awaq9or.fsf@laas.fr> Hi, Kip Warner writes: > I have heard that OpenPGP isn't quite up to par yet and still buggy. In GnuTLS 2.0.x, it works quite well AFAICS. Thanks, Ludovic. From simon at josefsson.org Wed Oct 17 16:31:27 2007 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 17 Oct 2007 16:31:27 +0200 Subject: [Help-gnutls] GnuTLS 2.0.2 Message-ID: <87lka1ersw.fsf@mocca.josefsson.org> We are pleased to announce a new stable GnuTLS release: Version 2.0.2. GnuTLS is a modern C library that implement the standard network security protocol Transport Layer Security (TLS), for use by network applications. GnuTLS is developed for GNU/Linux, but works on many Unix-like systems and comes with a binary installer for Windows. The core GnuTLS library is distribute under the terms of the GNU Lesser General Public License version 2.1 (or later). The "extra" GnuTLS libraries -- which contains OpenPGP and TLS/IA support, LZO2 compression, the OpenSSL compatibility library -- and the self tests and command line tools are distributed under the GNU General Public License version 2.0 (or later). The manual is distributed under the GNU Free Documentation License version 1.2 (or later). The project page of the library is available at: http://www.gnutls.org/ http://www.gnu.org/software/gnutls/ http://josefsson.org/gnutls/ What's New ========== The following changes have been made since GnuTLS 2.0.1: ** TLS authorization support removed. This technique may be patented in the future, and it is not of crucial importance for the Internet community. After deliberation we have concluded that the best thing we can do in this situation is to encourage society not to adopt this technique. We have decided to lead the way with our own actions. ** certtool: Fixed data corruption when using --outder. ** Fix configure-time Guile detection. ** API and ABI modifications: GNUTLS_SUPPLEMENTAL_USER_MAPPING_DATA: ADDED. To avoid that the gnutls_supplemental_data_format_type_t enum type becomes empty. Getting the Software ==================== GnuTLS may be downloaded from one of the mirror sites or direct from . The list of mirrors can be found at . Note, that GnuPG is not available at ftp.gnu.org. Here are the BZIP2 compressed sources (4.7MB): ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.0.2.tar.bz2 http://josefsson.org/gnutls/releases/gnutls-2.0.2.tar.bz2 Here are OpenPGP detached signatures signed using key 0xB565716F: ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.0.2.tar.bz2.sig http://josefsson.org/gnutls/releases/gnutls-2.0.2.tar.bz2.sig Note, that we don't distribute gzip compressed tarballs. In order to check that the version of GnuTLS which you are going to install is an original and unmodified one, you should verify the OpenPGP signature. You can use the command gpg --verify gnutls-2.0.2.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. The signing key can be identified with the following information: pub 1280R/B565716F 2002-05-05 [expires: 2008-06-30] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2008-06-30] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Alternatively, after successfully verifying the OpenPGP signature of this announcement, you could verify that the files match the following checksum values. The values are for SHA-1 and SHA-224 respectively: 1e67565e1dbdfdbcf67a7467f7507f849e582730 gnutls-2.0.2.tar.bz2 8a87fe115e0514bdb1ddaf33a5762d57e6387e2d99a06f4c7eb0dffc gnutls-2.0.2.tar.bz2 Documentation ============= The manual is available online at: http://www.gnu.org/software/gnutls/documentation.html In particular the following formats are available: HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf For developers there is a GnuTLS API reference manual formatted using the GTK-DOC tools: http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html Community ========= If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: . If you wish to participate in the development of GnuTLS, you are invited to join our gnutls-dev mailing list, see: . Windows installer ================= GnuTLS has been ported to the Windows operating system, and a binary installer is available. The installer contains DLLs for application development, manuals, examples, and source code. The installer consists of libgpg-error 1.5, libgcrypt 1.3.0, libtasn1 1.1, opencdk 0.6.4, and GnuTLS 2.0.2. For more information about GnuTLS for Windows: http://josefsson.org/gnutls4win/ Internationalization ==================== GnuTLS messages have been translated into German, Malay, Polish and Swedish. We welcome the addition of more translations. Support ======= Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. The GnuTLS service directory is available at: http://www.gnu.org/software/gnutls/commercial.html Happy Hacking, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From Kip at TheVertigo.com Wed Oct 17 22:00:44 2007 From: Kip at TheVertigo.com (Kip Warner) Date: Wed, 17 Oct 2007 13:00:44 -0700 (PDT) Subject: [Help-gnutls] Beginner Questions In-Reply-To: <873awaq9or.fsf@laas.fr> References: <13177782.post@talk.nabble.com> <200710122250.15732.nmav@gnutls.org> <13184749.post@talk.nabble.com> <87fy0cyc1f.fsf@laas.fr> <13223250.post@talk.nabble.com> <873awaq9or.fsf@laas.fr> Message-ID: <13261813.post@talk.nabble.com> Now lets just hope the new version of the runtimes and dev package will be in the repository for tomorrow's release of Gutsy. Kip -- View this message in context: http://www.nabble.com/Beginner-Questions-tf4614419.html#a13261813 Sent from the Gnu - TLS mailing list archive at Nabble.com. From colin at colino.net Thu Oct 18 09:47:10 2007 From: colin at colino.net (Colin Leroy) Date: Thu, 18 Oct 2007 09:47:10 +0200 Subject: [Help-gnutls] libgnutls: Verifying certificate chains, disconnected Message-ID: <20071018094710.701e0f39@colino.net> Hello, I'm one of the Claws Mail developers, and started integrating GnuTLS to replace OpenSSL as our ssl library. Most of it works fine already, I just have a few problems in the certificate verification area. First thing: if I understand correctly, GnuTLS doesn't ship a list of trusted CAs like openSSL. in order to be able to verify certificates and present them as valid, I have to do something like gnutls_certificate_set_x509_trust_file(xcred, "/etc/ssl/certs/ca-certificates.crt"); (this file comes from OpenSSL), then gnutls_certificate_verify_peers2(session, &status); Then I'm able to get valid certificates from, for example, pop.gmail.com. The other problem, more important imho than having to set a trust file, is that it seems I can do this only when I have a connected session. Claws Mail stores known certificates on disk, and has an SSL certificates manager UI, in which you can list and display the certificates it has stored. At this step however, there's no connection to the server running, so I can only use gnutls_x509_crt_verify(), and that doesn't check the issuer certificate(s), so I always have GNUTLS_CERT_INVALID... Whereas using OpenSSL, I could use X509_verify_cert(&store) and openssl checks the whole chain. Do you have any pointers for that? Thanks a lot in advance, -- Colin From simon at josefsson.org Thu Oct 18 15:34:25 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 18 Oct 2007 15:34:25 +0200 Subject: [Help-gnutls] Re: libgnutls: Verifying certificate chains, disconnected In-Reply-To: <20071018094710.701e0f39@colino.net> (Colin Leroy's message of "Thu, 18 Oct 2007 09:47:10 +0200") References: <20071018094710.701e0f39@colino.net> Message-ID: <876414a6n2.fsf@mocca.josefsson.org> Colin Leroy writes: > Hello, > > I'm one of the Claws Mail developers, and started integrating GnuTLS to > replace OpenSSL as our ssl library. Most of it works fine already, I > just have a few problems in the certificate verification area. > > First thing: if I understand correctly, GnuTLS doesn't ship a list of > trusted CAs like openSSL. in order to be able to verify certificates > and present them as valid, I have to do something like > > gnutls_certificate_set_x509_trust_file(xcred, > "/etc/ssl/certs/ca-certificates.crt"); > > (this file comes from OpenSSL), then I believe most distributions (e.g., Debian) maintain that file. I couldn't find a 'ca-certificates.crt' file in openssl 0.9.8e, although I didn't look very carefully. > gnutls_certificate_verify_peers2(session, &status); > > Then I'm able to get valid certificates from, for example, > pop.gmail.com. You'll need to do more than that to verify pop.gmail.com's certificate, there is an example in the manual: http://www.gnu.org/software/gnutls/manual/html_node/Verifying-peer_0027s-certificate.html You may want to look at the source for 'msmtp' and/or 'mpop' utilities, they use GnuTLS and claims to do proper certificate verification: http://msmtp.sourceforge.net/ http://mpop.sourceforge.net/ Possibly there should be a simple utility function that does everything, but this is quite application dependent so it is difficult to implement it. Generally, I think that ideally the X.509 stuff should be in another library than GnuTLS. That would make things more modular and the interface between TLS the protocol and X.509 the certificate format more clear. > The other problem, more important imho than having to set a trust file, > is that it seems I can do this only when I have a connected session. > Claws Mail stores known certificates on disk, and has an SSL > certificates manager UI, in which you can list and display the > certificates it has stored. > > At this step however, there's no connection to the server running, so I > can only use gnutls_x509_crt_verify(), and that doesn't check the issuer > certificate(s), so I always have GNUTLS_CERT_INVALID... Whereas using > OpenSSL, I could use X509_verify_cert(&store) and openssl checks the > whole chain. > > Do you have any pointers for that? Check the source code for gnutls_certificate_verify_peers2, it contains what you have to do externally. I don't think if there is a better interface available. /Simon From colin at colino.net Fri Oct 19 09:30:29 2007 From: colin at colino.net (Colin Leroy) Date: Fri, 19 Oct 2007 07:30:29 +0000 Subject: [Help-gnutls] Re: libgnutls: Verifying certificate chains, disconnected In-Reply-To: <876414a6n2.fsf@mocca.josefsson.org> References: <20071018094710.701e0f39@colino.net> <876414a6n2.fsf@mocca.josefsson.org> Message-ID: <20071019073029.394755f0@paperstreet.colino.net> On Thu, 18 Oct 2007 15:34:25 +0200, Simon Josefsson wrote: Hi, > I believe most distributions (e.g., Debian) maintain that file. I > couldn't find a 'ca-certificates.crt' file in openssl 0.9.8e, > although I didn't look very carefully. Ah, you're right, it's provided by another package, ca-certificates. > > gnutls_certificate_verify_peers2(session, &status); > > > > Then I'm able to get valid certificates from, for example, > > pop.gmail.com. > > You'll need to do more than that to verify pop.gmail.com's > certificate, there is an example in the manual: Indeed, there's also the validity date and the hostname to check... I forgot those :) > > At this step however, there's no connection to the server running, > > so I can only use gnutls_x509_crt_verify(), and that doesn't check > > the issuer certificate(s), so I always have GNUTLS_CERT_INVALID... > > Whereas using OpenSSL, I could use X509_verify_cert(&store) and > > openssl checks the whole chain. > > > > Do you have any pointers for that? > > Check the source code for gnutls_certificate_verify_peers2, it > contains what you have to do externally. I don't think if there is a > better interface available. I've looked at it, but this code seems really closely interlaced with things done at session start, and I couldn't figure out how to get the certificates list starting from a gnutls_x509_crt... -- Colin From simon at josefsson.org Fri Oct 19 11:18:08 2007 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 19 Oct 2007 11:18:08 +0200 Subject: [Help-gnutls] Re: libgnutls: Verifying certificate chains, disconnected In-Reply-To: <20071019073029.394755f0@paperstreet.colino.net> (Colin Leroy's message of "Fri, 19 Oct 2007 07:30:29 +0000") References: <20071018094710.701e0f39@colino.net> <876414a6n2.fsf@mocca.josefsson.org> <20071019073029.394755f0@paperstreet.colino.net> Message-ID: <873aw7qx7z.fsf@mocca.josefsson.org> Colin Leroy writes: >> > At this step however, there's no connection to the server running, >> > so I can only use gnutls_x509_crt_verify(), and that doesn't check >> > the issuer certificate(s), so I always have GNUTLS_CERT_INVALID... >> > Whereas using OpenSSL, I could use X509_verify_cert(&store) and >> > openssl checks the whole chain. >> > >> > Do you have any pointers for that? >> >> Check the source code for gnutls_certificate_verify_peers2, it >> contains what you have to do externally. I don't think if there is a >> better interface available. > > I've looked at it, but this code seems really closely interlaced with > things done at session start, and I couldn't figure out how to get the > certificates list starting from a gnutls_x509_crt... The server provides the list, so if you are offline you need to construct the list yourself somehow. The X.509 interface in GnuTLS isn't ideal for non-TLS purposes, perhaps your needs are better served by creating a 'libx509' with the relevant functions stripped out from GnuTLS and improved with the functions you need. Or we could extend libksba, which is GnuPG's X.509 library. /Simon From nmav at gnutls.org Fri Oct 19 14:45:31 2007 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 19 Oct 2007 15:45:31 +0300 Subject: [Help-gnutls] Re: libgnutls: Verifying certificate chains, disconnected In-Reply-To: <20071019073029.394755f0@paperstreet.colino.net> References: <20071018094710.701e0f39@colino.net> <876414a6n2.fsf@mocca.josefsson.org> <20071019073029.394755f0@paperstreet.colino.net> Message-ID: <200710191545.31580.nmav@gnutls.org> On Friday 19 October 2007, Colin Leroy wrote: > > > Do you have any pointers for that? > > > > Check the source code for gnutls_certificate_verify_peers2, it > > contains what you have to do externally. I don't think if there is a > > better interface available. > > I've looked at it, but this code seems really closely interlaced with > things done at session start, and I couldn't figure out how to get the > certificates list starting from a gnutls_x509_crt... I don't really understand what you want to do. Do you have certificates in gnutls_x509_crt structures and you want to verify them? Or do you have them in der (or pem) format and you want to import them to x509_crt structures? We do certificate verification in certtool using the --verify-chain option, is this the functionality you are trying to achieve? regards, Nikos From mrsam at courier-mta.com Sat Oct 20 22:25:45 2007 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sat, 20 Oct 2007 16:25:45 -0400 Subject: [Help-gnutls] gnutls_handshake fails with an alert Message-ID: I've taken the "Simple client example" from the 1.6.3 pages, and supplied a tcp_connect() that connects to ssl-enabled apache on localhost. Running the code results in: *** Handshake failed GNUTLS ERROR: A TLS fatal alert has been received. My apache SSL config works fine (with a self-signed cert). Just to eliminate the self-signed cert being a factor, I also tried and got the same results with mail.google.com on port 443 (gmail over https). I can see from strace that the alert seems to be genuine. After a: connect(4, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 ? it looks like I'm sending a record, and receiving a small alert in response: sendto(4, "\26\3\1\0001\1\0\0-\3\1G\32c918\23Ul\t\366c\22l76\254\335\4\254\273"?, 54, 0, NULL, 0) = 54 recvfrom(4, "\25\3\1\0\2", 5, 0, NULL, NULL) = 5 recvfrom(4, "\2(", 2, 0, NULL, NULL) = 2 write(2, "*** Handshake failed\n", 21*** Handshake failed But I'm only using the simple client example, from the info pages, as is, so what's going wrong here? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nmav at gnutls.org Sun Oct 21 22:48:27 2007 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 21 Oct 2007 23:48:27 +0300 Subject: [Help-gnutls] gnutls_handshake fails with an alert In-Reply-To: References: Message-ID: <200710212348.27544.nmav@gnutls.org> On Saturday 20 October 2007, Sam Varshavchik wrote: > I've taken the "Simple client example" from the 1.6.3 pages, and supplied a > tcp_connect() that connects to ssl-enabled apache on localhost. Running the > code results in: > > *** Handshake failed > GNUTLS ERROR: A TLS fatal alert has been received. What you say doesn't help anyone who might want to help. It can be an error in your tcp functions, or you might be using the anonymous client to connect to a X.509 authenticated server. regards, Nikos From mrsam at courier-mta.com Mon Oct 22 00:29:51 2007 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sun, 21 Oct 2007 18:29:51 -0400 Subject: [Help-gnutls] gnutls_handshake fails with an alert References: <200710212348.27544.nmav@gnutls.org> Message-ID: Nikos Mavrogiannopoulos writes: > On Saturday 20 October 2007, Sam Varshavchik wrote: >> I've taken the "Simple client example" from the 1.6.3 pages, and supplied a >> tcp_connect() that connects to ssl-enabled apache on localhost. Running the >> code results in: >> >> *** Handshake failed >> GNUTLS ERROR: A TLS fatal alert has been received. > > What you say doesn't help anyone who might want to help. It can be an error in > your tcp functions, or you might be using the anonymous client to connect to > a X.509 authenticated server. No, I'm running a default Apache install with mod_ssl. I finally ended up looking at elinks's source to see how it sets up gnutls. It turned out that I needed to create a gnutls_certificate_credentials_t using gnutls_certificate_allocate_credentials(), and put it into the session using gnutls_credentials_set(). Once I did that, the example given in the info docs worked correctly, both with my stock Apache, and other external SSL servers. I am NOT using X.509 authentication, I'm running just a basic, plain-vanilla Apache+mod_ssl, using a self-signed test cert, without any X.509 authentication set up. It looks to me like the simple client example won't really work with garden-variety SSL servers. Looks like I need to put a GNUTLS_CRD_CERTIFICATE into a client session structure even if the server does not use or require X.509 authentication, in order for the handshake to work. I couldn't find anything in info docs that pointed me in that direction, I had to look at some other code to figure it out. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From simon at josefsson.org Mon Oct 22 07:51:39 2007 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 22 Oct 2007 07:51:39 +0200 Subject: [Help-gnutls] Re: gnutls_handshake fails with an alert In-Reply-To: (Sam Varshavchik's message of "Sun, 21 Oct 2007 18:29:51 -0400") References: <200710212348.27544.nmav@gnutls.org> Message-ID: <87myub3dec.fsf@mocca.josefsson.org> Sam Varshavchik writes: > Nikos Mavrogiannopoulos writes: > >> On Saturday 20 October 2007, Sam Varshavchik wrote: >>> I've taken the "Simple client example" from the 1.6.3 pages, and supplied a >>> tcp_connect() that connects to ssl-enabled apache on localhost. Running the >>> code results in: >>> >>> *** Handshake failed >>> GNUTLS ERROR: A TLS fatal alert has been received. >> >> What you say doesn't help anyone who might want to help. It can be >> an error in your tcp functions, or you might be using the anonymous >> client to connect to a X.509 authenticated server. > > No, I'm running a default Apache install with mod_ssl. > > I finally ended up looking at elinks's source to see how it sets up > gnutls. It turned out that I needed to create a > gnutls_certificate_credentials_t using > gnutls_certificate_allocate_credentials(), and put it into the session > using gnutls_credentials_set(). Once I did that, the example given in > the info docs worked correctly, both with my stock Apache, and other > external SSL servers. > > I am NOT using X.509 authentication, I'm running just a basic, > plain-vanilla Apache+mod_ssl, using a self-signed test cert, without > any X.509 authentication set up. It looks to me like the simple client > example won't really work with garden-variety SSL servers. Looks like > I need to put a GNUTLS_CRD_CERTIFICATE into a client session structure > even if the server does not use or require X.509 authentication, in > order for the handshake to work. I couldn't find anything in info docs > that pointed me in that direction, I had to look at some other code to > figure it out. I believe that Apache/mod_ssl requires X.509, and refuses to handshake an anonymous cipher. There is a simple X.509 client GnuTLS example: http://www.gnu.org/software/gnutls/manual/html_node/Simple-client-example-with-X_002e509-certificate-support.html Generally, there are many servers out there that refuses to negotiate anonymous ciphers. So you typically need to configure X.509 to use TLS, even if it is just a self-signed test cert. /Simon From nmav at gnutls.org Mon Oct 22 10:05:59 2007 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 22 Oct 2007 11:05:59 +0300 Subject: [Help-gnutls] gnutls_handshake fails with an alert In-Reply-To: References: <200710212348.27544.nmav@gnutls.org> Message-ID: <200710221105.59810.nmav@gnutls.org> On Monday 22 October 2007, Sam Varshavchik wrote: > No, I'm running a default Apache install with mod_ssl. > > I finally ended up looking at elinks's source to see how it sets up gnutls. > It turned out that I needed to create a gnutls_certificate_credentials_t > using gnutls_certificate_allocate_credentials(), and put it into the > session using gnutls_credentials_set(). Once I did that, the example given > in the info docs worked correctly, both with my stock Apache, and other > external SSL servers. > I am NOT using X.509 authentication, I'm running just a basic, > plain-vanilla Apache+mod_ssl, using a self-signed test cert, without any > X.509 > authentication set up. The default apache with mod_ssl, as well as every other HTTPS server, do X.509 authentication. Elinks is not a good example to check. It doesn't check any certificate eventhough it uses authenticated ciphersuites. Check the examples in the gnutls documentation. regards, Nikos From Tom.Cort at state.vt.us Tue Oct 23 13:43:25 2007 From: Tom.Cort at state.vt.us (Cort, Tom) Date: Tue, 23 Oct 2007 07:43:25 -0400 Subject: [Help-gnutls] License Info for Example Code Message-ID: Hi, I'm converting an HTTP library from OpenSSL to GNU TLS and I'm finding the GNU TLS manual very helpful; thank you for such a great doc. The example code included with the manual (see gnutls-2.1.3/doc/examples) is useful and I'd like to use some code snippets in my library, but I can't find the license information for the example code. None of the C files in the doc/examples directory have copyright notices. Can someone tell me what license those files are released under? Thanks! -- Tom Cort Systems Developer Vermont Department of Taxes From nmav at gnutls.org Tue Oct 23 14:40:40 2007 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 23 Oct 2007 15:40:40 +0300 Subject: [Help-gnutls] License Info for Example Code In-Reply-To: References: Message-ID: <200710231540.40883.nmav@gnutls.org> On Tuesday 23 October 2007, Cort, Tom wrote: > Hi, > I'm converting an HTTP library from OpenSSL to GNU TLS and I'm finding > the GNU TLS manual very helpful; thank you for such a great doc. The > example code included with the manual (see gnutls-2.1.3/doc/examples) is > useful and I'd like to use some code snippets in my library, but I can't > find the license information for the example code. None of the C files > in the doc/examples directory have copyright notices. Can someone tell > me what license those files are released under? You can assume this license: /* Copyright 2007 Free Software Foundation * * Copying and distribution of this file, with or without modification, * are permitted in any medium without royalty provided the copyright * notice and this notice are preserved. */ We'll make this explicit in future versions. regards, Nikos From Tom.Cort at state.vt.us Tue Oct 23 15:19:09 2007 From: Tom.Cort at state.vt.us (Cort, Tom) Date: Tue, 23 Oct 2007 09:19:09 -0400 Subject: [Help-gnutls] License Info for Example Code In-Reply-To: <200710231540.40883.nmav@gnutls.org> References: <200710231540.40883.nmav@gnutls.org> Message-ID: Hi, Thanks for replying so quickly. > You can assume this license: > /* Copyright 2007 Free Software Foundation > * > * Copying and distribution of this file, with or without modification, > * are permitted in any medium without royalty provided the copyright > * notice and this notice are preserved. > */ Is that license compatible with "GPLv3 or later" (i.e. can I copy and paste the examples into my GPLv3 or later software without violating either license provided I include the notice above)? How should the copyright header in my program look? Is this okay... /* * libfoo - bar bar bar. * Copyright (C) 2007 Vermont Department of Taxes * * This program is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program. If not, see . * * --- * * GNU TLS Examples - ex-session-info.c, ex-rfc2818.c, ex-client2.c * Copyright 2007 Free Software Foundation * * Copying and distribution of this file, with or without modification, * are permitted in any medium without royalty provided the copyright * notice and this notice are preserved. */ -- Tom Cort Systems Developer Vermont Department of Taxes From simon at josefsson.org Wed Oct 24 17:17:35 2007 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 24 Oct 2007 17:17:35 +0200 Subject: [Help-gnutls] Re: License Info for Example Code In-Reply-To: (Tom Cort's message of "Tue, 23 Oct 2007 09:19:09 -0400") References: <200710231540.40883.nmav@gnutls.org> Message-ID: <87640wh78w.fsf@mocca.josefsson.org> "Cort, Tom" writes: > Hi, > > Thanks for replying so quickly. > >> You can assume this license: >> /* Copyright 2007 Free Software Foundation >> * >> * Copying and distribution of this file, with or without > modification, >> * are permitted in any medium without royalty provided the copyright >> * notice and this notice are preserved. >> */ > > Is that license compatible with "GPLv3 or later" (i.e. can I copy and > paste the examples into my GPLv3 or later software without violating > either license provided I include the notice above)? How should the > copyright header in my program look? Is this okay... Since this is a general problem we have asked licensing at gnu.org to help us with the licensing. Generally, our intention is that the example programs should be possible to use everywhere without limitation. Thanks, Simon > /* > * libfoo - bar bar bar. > * Copyright (C) 2007 Vermont Department of Taxes > * > * This program is free software: you can redistribute it and/or modify > * it under the terms of the GNU General Public License as published by > * the Free Software Foundation, either version 3 of the License, or > * (at your option) any later version. > * > * This program is distributed in the hope that it will be useful, > * but WITHOUT ANY WARRANTY; without even the implied warranty of > * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > * GNU General Public License for more details. > * > * You should have received a copy of the GNU General Public License > * along with this program. If not, see . > * > * --- > * > * GNU TLS Examples - ex-session-info.c, ex-rfc2818.c, ex-client2.c > * Copyright 2007 Free Software Foundation > * > * Copying and distribution of this file, with or without modification, > * are permitted in any medium without royalty provided the copyright > * notice and this notice are preserved. > */ > > -- > Tom Cort > Systems Developer > Vermont Department of Taxes