Re: Friendly name
A friendly name is a field of a certificate - typically if you check for example IE - you'll see a column entitled friendly name and most certificates have these. I believe the method I'm using below creates a certificate only - if I understand correctly PKCS12 is a type of certificate container so I am not sure if I need this? That said I have seen postings with a PKCS12 export and a -name option but was hoping there was similar option to add to the steps I'm doing below? - Original Message - From: owner-openssl-us...@openssl.org owner-openssl-us...@openssl.org To: openssl-users@openssl.org openssl-users@openssl.org Sent: Fri Dec 02 00:23:10 2011 Subject: Re: Friendly name On Thu, Dec 01, 2011, Hopkins, Nathan wrote: I'm using the below commands to create a ca ... openssl genrsa -des3 -out ca.key 2048 openssl req -new -x509 -key ca.key -out ca.crt -days 730 ... please can you advise how I can add a friendly name to this cert? What do you mean by friendly name: i.e. why do you want to add one and what do you expect it to do? There is a PKCS#12 attribute called friendlyName but adding this to a certificate is non-standard. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Friendly name
Hi, First, sorry for my previous response about an OID, I didn't check enough details before I posted. Based on what Dr.Henson wrote and my own knowledge, here is a better answer: The friendly name is NOT a field in a certificate. It is just a file name that the certificate be stored under in some programs, especially those from Mozilla and Microsoft. This would mean there are 2 ways to set the friendly name: A) Import the certificate (without the private key since this is supposed to be a secure CA) in the M or M software and set the friendly name in the user interface of that program. B) Use openssl to put the certificate (without the private key!) in a PKCS#12 certificate backup file and set the friendly name of the certificate in that PKCS#12 file, then import the PKCS#12 file to the M or M software. Because the friendly name is not part of the certificate itself, you don't need to create a new certificate when setting or changing the friendly name. It is something you can (and should) do with the completed certificate while NOT even having (nor letting the programs have) access to the private key. On 12/2/2011 9:01 AM, Hopkins, Nathan wrote: A friendly name is a field of a certificate - typically if you check for example IE - you'll see a column entitled friendly name and most certificates have these. I believe the method I'm using below creates a certificate only - if I understand correctly PKCS12 is a type of certificate container so I am not sure if I need this? That said I have seen postings with a PKCS12 export and a -name option but was hoping there was similar option to add to the steps I'm doing below? - Original Message - From: owner-openssl-us...@openssl.org owner-openssl-us...@openssl.org To: openssl-users@openssl.org openssl-users@openssl.org Sent: Fri Dec 02 00:23:10 2011 Subject: Re: Friendly name On Thu, Dec 01, 2011, Hopkins, Nathan wrote: I'm using the below commands to create a ca ... openssl genrsa -des3 -out ca.key 2048 openssl req -new -x509 -key ca.key -out ca.crt -days 730 ... please can you advise how I can add a friendly name to this cert? What do you mean by friendly name: i.e. why do you want to add one and what do you expect it to do? There is a PKCS#12 attribute called friendlyName but adding this to a certificate is non-standard. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: size of EVP_Seal* output
From: owner-openssl-us...@openssl.org On Behalf Of Jonas Schnelli Sent: Wednesday, 30 November, 2011 09:57 I try to pre-calculate the size of a EVP_Seal encrypted buffer (just the seal, exkl. keys). How do i precalculate that? I assume with some blocksize stuff (i'm a crypto novice). I'm using AES256 as EVP_CIPHER. The 'seal' or 'envelope' operation actually produces symmetrically encrypted data PLUS PK-encrypted/wrapped (nonce) key and optionally IV, and typically some recipient-identifier information. These are meaningless and unusable separately. I assume you mean to ask about only the encrypted bulk data. Yes. I mean the bulk data. The length of the encrypted session key and IV is known. If you use a block mode that requires padding (CBC or ECB, but don't use ECB unless you know what you're doing), the ciphertext will be up to one block longer than the plaintext, thus buffersize (if you use a single buffer instead of pieces) must be at least one block longer. In general this is EVP_CIPHER_[CTX_]block_size(ciph) and for AES it is 16 bytes. If you use a stream mode (CFB, OFB, CTR) (or a stream cipher, which AES isn't) ciphertext is same size as plaintext. Thanks for that! I try now to implement this and will read more about CFB/OFB/CTR. Thanks -- Jonas __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: renegotiation during a handshake failure
Thanks Jakob, Callback is a possibility but the limitation is that this callback does not have access to the filename (which can change for every client) to load all pem files. Also I do not want to read the file every time in call back. I was ablt to prototype my idea by recreating the SSL object from context and use it for SSL_Connect and SSL_accept. But unfortunately client is sending a fatal unexpected_message alert to server immediately after client hello. here is the ssl dump: New TCP connection #1: localhost.localdomain(10289) - localhost.localdomain(23037) 1 1 0.0001 (0.0001) CSV3.1(67) Handshake ClientHello Version 3.1 random[32]= 4e d8 a4 ee fd 9e be ec 58 1b 3e 16 fd a6 b2 e9 a5 fe 65 34 79 e4 65 03 81 d4 f2 b7 7a a8 ac 55 cipher suites TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_IDEA_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 compression methods NULL 1 2 0.0005 (0.0003) SCV3.1(74) Handshake ServerHello Version 3.1 random[32]= 4e d8 a4 ee a5 b1 69 b8 9a a1 e4 01 07 96 e4 a1 31 dc 7d b7 e3 01 48 4e d1 f1 21 c6 58 4e 74 ff session_id[32]= 81 98 54 07 4c 14 b2 37 d6 13 05 26 05 5f bc dd 46 5c d6 aa 9e ee 20 22 3e 13 7b 98 13 d0 30 ee cipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA compressionMethod NULL 1 3 0.0005 (0.) SCV3.1(1278) Handshake Certificate 1 4 0.0005 (0.) SCV3.1(160) Handshake CertificateRequest certificate_types rsa_sign certificate_types dss_sign certificate_types unknown value certificate_authority 30 81 8d 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 0b 30 09 06 03 55 04 08 13 02 43 61 31 11 30 0f 06 03 55 04 07 13 08 53 61 6e 20 4a 6f 73 65 31 1b 30 19 06 03 55 04 0a 13 12 50 61 79 50 61 30 1e 06 09 2a 86 48 86 f7 0d 01 09 01 16 11 70 76 6f 69 63 75 40 70 61 79 70 61 6c 2e 63 6f 6d ServerHelloDone 1 5 0.0008 (0.0003) CSV3.1(2) Alert level fatal value unknown_ca 1 6 0.0130 (0.0121) CSV3.1(67) Handshake ClientHello Version 3.1 random[32]= 4e d8 a4 ee 61 a7 5b 6c 64 89 61 fb cf 0a a2 85 65 04 40 47 23 0d 62 35 b4 59 b5 bb 2e b7 a8 22 cipher suites TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_IDEA_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 compression methods NULL *1 7 0.0130 (0.) CSV3.1(2) Alert* *level fatal* *value unexpected_message* 10.0130 (0.) CS TCP FIN 1 8 0.0131 (0.0001) SCV3.1(74) Handshake ServerHello Version 3.1 random[32]= 4e d8 a4 ee 42 58 23 7f 51 e4 c1 10 b6 9d f0 7e 25 bd 8a 95 3c e2 dd 0e 4d 3e 61 38 33 2b a9 58 session_id[32]= 5b ca 68 de 2f 18 cb 03 df 8b 23 b9 b0 19 87 7e 02 72 f7 bb e2 a5 21 6a 7e c8 a8 38 12 83 d8 fe cipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA compressionMethod NULL 1 9 0.0131 (0.) SCV3.1(1278) Handshake Certificate 1 10 0.0131 (0.) SCV3.1(160) Handshake CertificateRequest certificate_types rsa_sign certificate_types dss_sign certificate_types unknown value certificate_authority 30 81 8d 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 0b 30 09 06 03 55 04 08 13 02 43 61 31 11 30 0f 06 03 55 04 07 13 08 53 61 6e 20 4a 6f 73 65 0c 06 03 55 04 0b 13 05 49 6e 66 72 61 31 0f 30 0d 06 03 55 04 03 13 06 70 76 6f 69 63 75 31 20 30 1e 06 09 2a 86 48 86 f7 0d 01 09 01 16 11 70 76 6f 69 63 75 40 70 61 79 70 61 6c 2e 63 6f 6d ServerHelloDone Any help whatsoever to solve this will be highly appreciated. Thanks, handshak3 On Fri, Dec 2, 2011 at 3:42 AM, Jakob Bohm jb-open...@wisemo.com wrote: On 12/1/2011 6:33 PM, Rohit Bansal wrote: Hi, Let me start with a disclaimer that i am not very experienced with openssl. I have a
Re: renegotiation during a handshake failure
Your callback should have access to the Global data in your program, which can include both that file name and variables to hold on to the loaded PEM file once loaded by the first session needing it. On 12/2/2011 12:09 PM, Rohit Bansal wrote: Thanks Jakob, Callback is a possibility but the limitation is that this callback does not have access to the filename (which can change for every client) to load all pem files. Also I do not want to read the file every time in call back. I was ablt to prototype my idea by recreating the SSL object from context and use it for SSL_Connect and SSL_accept. But unfortunately client is sending a fatal unexpected_message alert to server immediately after client hello. here is the ssl dump: New TCP connection #1: localhost.localdomain(10289) - localhost.localdomain(23037) 1 1 0.0001 (0.0001) CSV3.1(67) Handshake ClientHello Version 3.1 random[32]= 4e d8 a4 ee fd 9e be ec 58 1b 3e 16 fd a6 b2 e9 a5 fe 65 34 79 e4 65 03 81 d4 f2 b7 7a a8 ac 55 cipher suites TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_IDEA_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 compression methods NULL 1 2 0.0005 (0.0003) SCV3.1(74) Handshake ServerHello Version 3.1 random[32]= 4e d8 a4 ee a5 b1 69 b8 9a a1 e4 01 07 96 e4 a1 31 dc 7d b7 e3 01 48 4e d1 f1 21 c6 58 4e 74 ff session_id[32]= 81 98 54 07 4c 14 b2 37 d6 13 05 26 05 5f bc dd 46 5c d6 aa 9e ee 20 22 3e 13 7b 98 13 d0 30 ee cipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA compressionMethod NULL 1 3 0.0005 (0.) SCV3.1(1278) Handshake Certificate 1 4 0.0005 (0.) SCV3.1(160) Handshake CertificateRequest certificate_types rsa_sign certificate_types dss_sign certificate_types unknown value certificate_authority 30 81 8d 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 0b 30 09 06 03 55 04 08 13 02 43 61 31 11 30 0f 06 03 55 04 07 13 08 53 61 6e 20 4a 6f 73 65 31 1b 30 19 06 03 55 04 0a 13 12 50 61 79 50 61 30 1e 06 09 2a 86 48 86 f7 0d 01 09 01 16 11 70 76 6f 69 63 75 40 70 61 79 70 61 6c 2e 63 6f 6d ServerHelloDone 1 5 0.0008 (0.0003) CSV3.1(2) Alert level fatal value unknown_ca 1 6 0.0130 (0.0121) CSV3.1(67) Handshake ClientHello Version 3.1 random[32]= 4e d8 a4 ee 61 a7 5b 6c 64 89 61 fb cf 0a a2 85 65 04 40 47 23 0d 62 35 b4 59 b5 bb 2e b7 a8 22 cipher suites TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_IDEA_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 compression methods NULL *1 7 0.0130 (0.) CSV3.1(2) Alert* *level fatal* *value unexpected_message* 10.0130 (0.) CS TCP FIN 1 8 0.0131 (0.0001) SCV3.1(74) Handshake ServerHello Version 3.1 random[32]= 4e d8 a4 ee 42 58 23 7f 51 e4 c1 10 b6 9d f0 7e 25 bd 8a 95 3c e2 dd 0e 4d 3e 61 38 33 2b a9 58 session_id[32]= 5b ca 68 de 2f 18 cb 03 df 8b 23 b9 b0 19 87 7e 02 72 f7 bb e2 a5 21 6a 7e c8 a8 38 12 83 d8 fe cipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA compressionMethod NULL 1 9 0.0131 (0.) SCV3.1(1278) Handshake Certificate 1 10 0.0131 (0.) SCV3.1(160) Handshake CertificateRequest certificate_types rsa_sign certificate_types dss_sign certificate_types unknown value certificate_authority 30 81 8d 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 0b 30 09 06 03 55 04 08 13 02 43 61 31 11 30 0f 06 03 55 04 07 13 08 53 61 6e 20 4a 6f 73 65 0c 06 03 55 04 0b 13 05 49 6e 66 72 61 31 0f 30 0d 06 03 55 04 03 13 06 70 76 6f 69 63 75 31 20 30 1e 06 09 2a 86 48 86 f7 0d 01 09 01 16 11 70 76 6f 69 63 75 40 70 61 79 70 61 6c 2e 63 6f 6d ServerHelloDone Any help whatsoever to solve this will
Re: Decrypted buffer padding
Hi again, Hi, ** ** Thanks for your reply. ** ** I am aware of CipherFinal() but I wonder why CipherUpdate() writes anything into the final buffer at all if the buffer size is a multiple of the padding size. It looks a bit strange. The CipherUpdate() should implement a symmetric block cipher. Thus, the CipherUpdate() should write anything into the final buffer if the buffer size is multiple of the block size. If don't, the CipherFinal() will encrypt the exceeding bytes. Additionally CipherFinal() fails if I call it afterwards. Consider that I'm only a beginner OpenSSL user, anyway, I suggest to use the EVP_EncryptUpdate() and the EVP_EncryptFinal_ex(), they worked fine for me. ** ** The documentation says “as a result the amount of data written may be anything from zero bytes to (inl + cipher_block_size - 1)”. From that I take it that usually the final buffer should only contain data of the size “cipher_block_size – 1” which is not the case with the described behaviour. ** ** Cheers Nico ** Cheers Andrea -- *Von:* owner-openssl-us...@openssl.org [mailto: owner-openssl-us...@openssl.org] *Im Auftrag von *Andrea Saracino *Gesendet:* Freitag, 2. Dezember 2011 00:31 *An:* openssl-users@openssl.org *Betreff:* Re: Decrypted buffer padding ** ** Hi, after you use the EVP_CipherUpdate(), you have to call the EVP_CipherFinal() to encrypt the remaining bytes. Refer to the documentation to see how to correctly pass the parameters: http://www.openssl.org/docs/crypto/EVP_EncryptInit.html. The same goes for the decryption. I hope this help. Cheers. Andrea Il giorno 01 dicembre 2011 12:31, Nico Flink fl...@coolux.de ha scritto: Hello, I am trying to decrypt a buffer whose size is a multiple of the padding size (n * 16 bytes). But instead of getting the whole buffer as a result from EVP_CipherUpdate() I only get “InSize – PaddingSize” decrypted bytes. I get this behaviour with padding enabled and disabled. Is this the correct behaviour and is there anything I can do about it? In my application I need the insize to equal the outsize. Thanks a lot for your help. Cheers Nico ** **
RE: Friendly name
Possibly do an asndump on a cert that has a friendly name and see what it's really doing? -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Hopkins, Nathan Sent: Thursday, December 01, 2011 4:36 PM To: openssl-users@openssl.org Subject: RE: Friendly name I looked through the OID and couldn't see anything - I'm sure this must be possible? -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Jakob Bohm Sent: 01 December 2011 21:22 To: openssl-users@openssl.org Subject: Re: Friendly name On 12/1/2011 9:25 PM, Hopkins, Nathan wrote: I'm using the below commands to create a ca ... openssl genrsa -des3 -out ca.key 2048 openssl req -new -x509 -key ca.key -out ca.crt -days 730 ** ... please can you advise how I can add a friendly name to this cert? ** The Friendly name is the extended attribute with OID 1.2.840.113549.1.9.20 I don't remember if openssl has a name for this attribute or if you will have to refer to the OID directly. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Unable to load certificate
First, check what type of file it is; i.e. file x509 if it is an ascii file, check the PEM header. The PEM header will tell you what kind of information is included. If it is a data file (binary), try to use asn1parse to parse the data. If it is an ASN1 encoded file, it would show the structure of the data. On Thu, Dec 1, 2011 at 2:23 PM, Hopkins, Nathan nathan.hopk...@fil.comwrote: I found the problem with this was it was pkcs7 ** ** ** ** *From:* Hopkins, Nathan *Sent:* 30 November 2011 18:52 *To:* openssl-users@openssl.org *Subject:* RE: Unable to load certificate ** ** When I try with …-inform der I get … ** ** 32328:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1306: 32328:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:380:Type=X509 ** ** ** ** *From:* owner-openssl-us...@openssl.org [mailto: owner-openssl-us...@openssl.org] *On Behalf Of *Erwin Himawan *Sent:* 30 November 2011 16:52 *To:* openssl-users@openssl.org *Subject:* Re: Unable to load certificate ** ** Try using openssl x509 -noout -text -in server.crt -inform der On Wed, Nov 30, 2011 at 10:28 AM, Hopkins, Nathan nathan.hopk...@fil.com wrote: Hi, please can anyone help - what could be the possible cause for the below - my expectation is the .crt should be in the .pem format but I'm getting the below? openssl x509 -noout -text -in server.crt unable to load certificate 31237:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1306: 31237:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:380:Type=X509_CINF 31237:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:749:Field=cert_info, Type=X509 31237:error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib:pem_oth.c:83: __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org ** **
LDAP Server Supporting Component Matching
Hi All, I am aware that this is not the right forum. However, I just wodering whether anybody knows any LDAP server (commercial or opensource) that supports searching certificate using component matching. Thanks, Erwin
RE: Decrypted buffer padding
From: owner-openssl-us...@openssl.org On Behalf Of Nico Flink Sent: Friday, 02 December, 2011 02:32 I am aware of CipherFinal() but I wonder why CipherUpdate() writes anything into the final buffer at all if the buffer size is a multiple of the padding size. Additionally CipherFinal() fails if I call it afterwards. Cryptographic padding, and in particular the PKCS#5 padding which is most widely used and OpenSSL defaults to, ALWAYS adds at least one byte to the data. In this respect it is not like typical database or COBOL (or FORTRAN!) padding which is not added if the data is 'full' (already the specified size). When padding is used (only for a block cipher in block mode), DecryptUpdate or CipherUpdate in decrypt mode will only decrypt and return the blocks known to be application data, i.e. followed by at least one more byte of ciphertext (typically one more block since you usually send/receive or store/fetch ciphertext in binary units of at least the cipher blocksize). DecryptFinal or CipherFinal checks that the buffered last block is complete (error if not), decrypts it, checks the padding is valid (or error) and removes it, and returns any data (none if the last block is all padding). The documentation says as a result the amount of data written may be anything from zero bytes to (inl + cipher_block_size - 1). From that I take it that usually the final buffer should only contain data of the size cipher_block_size - 1 which is not the case with the described behaviour. That figure is for EncryptUpdate and is the worst case to allow for a series of calls with varying alignment. In particular if you have B-1 bytes buffered (from previous call) and 'add' NB+1 bytes, you get NB+B=(NB+1)+(B-1) encrypted. For DecryptUpdate the man page says inl+B which I think is actually conservative. But if you put the output from Update(s) + Final into a single buffer, which you usually do, the combined total is: - no padding: output = input - encrypt padded: input + 1 = output = input + NB - decrypt padded: input - NB = output = input - 1 snip Il giorno 01 dicembre 2011 12:31, Nico Flink fl...@coolux.de ha scritto: I am trying to decrypt a buffer whose size is a multiple of the padding size (n * 16 bytes). But instead of getting the whole buffer as a result from EVP_CipherUpdate() I only get InSize - PaddingSize decrypted bytes. I get this behaviour with padding enabled and disabled. Is this the correct behaviour and is there anything I can do about it? In my application I need the insize to equal the outsize. See above. With padding you should get csize - 16 from Update (or a series of Updates) and the last 0 to 15 from Final. The total plaintext size will always be at least 1 byte less than the ciphertext size (or equivalently ciphertext always at least 1 more than plaintext). This is inherent in the padding scheme and you must live with it in order to have arbitrary-length plaintext in a block mode. Alternatives are: - use a block mode with no padding and your data must always be an exact multiple of the block size. This is usually inconvenient. - use a stream mode or stream cipher If you decrypt without padding, I don't recall if that actually turns off buffering, but between Update + Final you should get plaintext size exactly equal to ciphertext size, which must be integral blocks (for a block cipher and mode) else error. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: anonymous DH for DTLS
From: owner-openssl-us...@openssl.org On Behalf Of Odomae Bro Sent: Thursday, 01 December, 2011 20:59 I used the built in s_server and s_client (command line) as follows and the ssl connection is established. openssl s_server -nocert -cipher aNULL openssl s_client -cipher aNULL However when I add the dtls1 option , this fails i.e openssl s_server -nocert -cipher aNULL - dtls1 openssl s_client -cipher aNULL -dtls1 Any idea why anon DH wont work for dtls? No. I don't normally use DTLS myself and am not familiar with any differences from normal TLS, but I tried exactly what you show (except your mistyped space between - dtls1) on my current dev build (vanilla 1.0.0e) and it works (selecting AECDH-AES256-SHA). Falling back on my usual protocol debugging: add -msg on s_client. How far in the handshake do you get, and then how does it vary from what should happen? Is there an alert either direction and what is it? Exactly what error does s_client and/or s_server show? What version, and how was it built (e.g. options)? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Friendly name
Many thanks Jakob / Dr.Henson - so would the below be the full process? openssl genrsa -des3 -out ca.key 2048 openssl req -new -x509 -key ca.key -out ca.crt -days 730 openssl pkcs12 -export -in ca.crt -out newca.crt -name My Certificate Are there any implications of put the cert inside a pkcs12 container? -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Jakob Bohm Sent: 02 December 2011 09:10 To: openssl-users@openssl.org Subject: Re: Friendly name Hi, First, sorry for my previous response about an OID, I didn't check enough details before I posted. Based on what Dr.Henson wrote and my own knowledge, here is a better answer: The friendly name is NOT a field in a certificate. It is just a file name that the certificate be stored under in some programs, especially those from Mozilla and Microsoft. This would mean there are 2 ways to set the friendly name: A) Import the certificate (without the private key since this is supposed to be a secure CA) in the M or M software and set the friendly name in the user interface of that program. B) Use openssl to put the certificate (without the private key!) in a PKCS#12 certificate backup file and set the friendly name of the certificate in that PKCS#12 file, then import the PKCS#12 file to the M or M software. Because the friendly name is not part of the certificate itself, you don't need to create a new certificate when setting or changing the friendly name. It is something you can (and should) do with the completed certificate while NOT even having (nor letting the programs have) access to the private key. On 12/2/2011 9:01 AM, Hopkins, Nathan wrote: A friendly name is a field of a certificate - typically if you check for example IE - you'll see a column entitled friendly name and most certificates have these. I believe the method I'm using below creates a certificate only - if I understand correctly PKCS12 is a type of certificate container so I am not sure if I need this? That said I have seen postings with a PKCS12 export and a -name option but was hoping there was similar option to add to the steps I'm doing below? - Original Message - From: owner-openssl-us...@openssl.org owner-openssl-us...@openssl.org To: openssl-users@openssl.org openssl-users@openssl.org Sent: Fri Dec 02 00:23:10 2011 Subject: Re: Friendly name On Thu, Dec 01, 2011, Hopkins, Nathan wrote: I'm using the below commands to create a ca ... openssl genrsa -des3 -out ca.key 2048 openssl req -new -x509 -key ca.key -out ca.crt -days 730 ... please can you advise how I can add a friendly name to this cert? What do you mean by friendly name: i.e. why do you want to add one and what do you expect it to do? There is a PKCS#12 attribute called friendlyName but adding this to a certificate is non-standard. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
FW: Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg.
Accidentally sent privately, copying to list for anyone else interested From: Dave Thompson [mailto:dthomp...@prinpay.com] Sent: Friday, 02 December, 2011 17:47 To: 'Ashok C' Subject: RE: Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg. From: Ashok C [mailto:ash@gmail.com] Sent: Friday, 02 December, 2011 00:11 Keeping the things you have mentioned in mind, this is how it goes. In server side, EE key is loaded using SSL_CTX_use_RSAPrivateKey_file(ctx,eekeyfile,SSL_FILETYPE_PEM); EE certificate is loaded using SSL_CTX_use_certificate_file(ctx, eepemfile,SSL_FILETYPE_PEM); And the intermediate certificate chain is loaded using SSL_CTX_use_certificate_chain_file(ctx, interchain) - This chain contains intermediate CA certs without the rootCA. In client side, rootCA is loaded using SSL_CTX_load_verify_locations(ctx,capemfile,NULL). After attempting SSL_connect from client, the intermediate certificate chain and the EE certificate are received in client side using SSL_get_peer_cert_chain(ssl) and SSL_get_peer_certificate (ssl) respectively. After this we call SSL_get_verify_result(ssl) which fails. So question here is that whether we need to add the received chain explicitly to the verify locations in client side? Meaning, do we need to build the chain from client side explicitly by ourselves? First, I made a mistake; it's been a long time since I coded this. CTX_use_certificate_chain_file loads BOTH the entity cert (which must be first in the file) AND the chain certs, and thus REPLACES CTX_use_certificate_file. I'm guessing you have that data, since if _use_certificate_chain_ doesn't contain the EE cert then handshake can't select this auth type (and we have no other) which produces a rather different (and less helpful!) error. But even with that done/fixed in my test environment I DO get verify error 24 invalid CA cert depth 1 (my only intermediate). Is that what you're getting? If so, it looks like maybe the 'purpose' checks have been made stricter since the last time I did this in test, where I have V1/noextension certs. I can't set up a test with real(er) (CA)certs immediately. If you have V1 or otherwise 'substandard' CA certs, you might try enhancing those. These specific checks appear to be bypassed for certs in the truststore, so putting all of the chain above the server EE in the client truststore is an alternative (and works for me). In that case the server only needs to send its EE cert (i.e. only _use_certificate). This is typically more work to set up and manage 'in the wild', but it is an alternative. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg.
Hi Dave, But even with that done/fixed in my test environment I DO get verify error 24 invalid CA cert depth 1 (my only intermediate). Is that what you're getting? If so, it looks like maybe the 'purpose' checks have been made stricter since the last time I did this in test, where I have V1/noextension certs. I can't set up a test with real(er) (CA)certs immediately. If you have V1 or otherwise 'substandard' CA certs, you might try enhancing those. Yes, I was getting the same error. And after using v3 certificates, the error did not appear again and my client-server app is working well with the multi-level configuration. Thanks a lot for your patient help in this regard. Regds, Ashok On Sat, Dec 3, 2011 at 4:17 AM, Dave Thompson dthomp...@prinpay.com wrote: From: Ashok C [mailto:ash@gmail.com] Sent: Friday, 02 December, 2011 00:11 Keeping the things you have mentioned in mind, this is how it goes. In server side, EE key is loaded using SSL_CTX_use_RSAPrivateKey_file(ctx,eekeyfile,SSL_FILETYPE_PEM); EE certificate is loaded using SSL_CTX_use_certificate_file(ctx, eepemfile,SSL_FILETYPE_PEM); And the intermediate certificate chain is loaded using SSL_CTX_use_certificate_chain_file(ctx, interchain) - This chain contains intermediate CA certs without the rootCA. In client side, rootCA is loaded using SSL_CTX_load_verify_locations(ctx,capemfile,NULL). After attempting SSL_connect from client, the intermediate certificate chain and the EE certificate are received in client side using SSL_get_peer_cert_chain(ssl) and SSL_get_peer_certificate (ssl) respectively. After this we call SSL_get_verify_result(ssl) which fails. So question here is that whether we need to add the received chain explicitly to the verify locations in client side? Meaning, do we need to build the chain from client side explicitly by ourselves? First, I made a mistake; it's been a long time since I coded this. CTX_use_certificate_chain_file loads BOTH the entity cert (which must be first in the file) AND the chain certs, and thus REPLACES CTX_use_certificate_file. I'm guessing you have that data, since if _use_certificate_chain_ doesn't contain the EE cert then handshake can't select this auth type (and we have no other) which produces a rather different (and less helpful!) error. But even with that done/fixed in my test environment I DO get verify error 24 invalid CA cert depth 1 (my only intermediate). Is that what you're getting? If so, it looks like maybe the 'purpose' checks have been made stricter since the last time I did this in test, where I have V1/noextension certs. I can't set up a test with real(er) (CA)certs immediately. If you have V1 or otherwise 'substandard' CA certs, you might try enhancing those. These specific checks appear to be bypassed for certs in the truststore, so putting all of the chain above the server EE in the client truststore is an alternative (and works for me). In that case the server only needs to send its EE cert (i.e. only _use_certificate). This is typically more work to set up and manage 'in the wild', but it is an alternative.
Please Help: Certificate Validation using subjectAltName extension
Dear All, My TLS client can validate both CN and SN i need to test both the scenario. I don't know how to create certificate with “subjectAltName extension” using openssl commands. In the RFC-2818 , there are two ways of Certificate Validation for Host name 1) CN (Common Name) 2) SN( Subject Name) If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead. I created Self-signed certificate using open-ssl commands and my certificate chain looks like below where CN=10.204.4.69 openssl genrsa -des3 -out server.key 1024 openssl req -new -key server.key -out server.csr openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt My Certificate chain === 0 s:/C=IN/ST=Karnataka/L=Bangalore/O=Home Inc/OU=TLS/CN=10.204.4.69/emailAddress=ssr...@www.https.com i:/C=IN/ST=Karnataka/L=Bangalore/O=Home Inc/OU=TLS/CN=10.204.4.69/emailAddress=ssr...@www.https.com Please tell how to create certificate with “subjectAltName extension” using openssl commands ? Thanks in advance. Regards, Rout -- View this message in context: http://old.nabble.com/Please-Help%3A-Certificate-Validation-using-subjectAltName-extension-tp32906983p32906983.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
