Re: linking errors on linux........!
Specifying -lssl is sufficient. libssl depends on libcrypto and so will be automatically linked indirectly to your app. e.g. gcc main.c -lssl -o sample will work. On Monday 16 June 2008 15:13:19 vinni rathore wrote: Hi.. first of all thanx as I got success using -lssl option with my file but could you please give me the whole procedure that why the linking errors?? how to link with the Library it needed .. i think in linux it require Libcrypto.so and libssl.so.. please provide me the steps.. thnx in advance regards, Vinni -- mit freundlichen Grüßen / best regards Gerhard Gappmeier ascolab GmbH - automation system communication laboratory Tel.: +49 9131 691 123 Fax: +49 9131 691 128 Web: http://www.ascolab.com GPG-Key: http://www.ascolab.com/gpg/gg.asc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Difference in packet contents
Hi, Actually, AES is by default implemented in CBC (Cipher Block Chaining )mode in TLSv1. Refer RFC 3268. Since the encryption is done in CBC mode, you will not get the same encrypted text for identical plain text. --lakshmi prasanna On Tue, Jun 17, 2008 at 10:58 AM, jimmy bahuleyan [EMAIL PROTECTED] wrote: Vijay Kotari wrote: @DS Nicely put. So, if I was to try to decrypt/encrypt one of these messages, I would need the key and the iv and something else? Because if just the key and iv are sufficient to encrypt/decrypt the data, then how are the different encrypted messages generated for the same cleartext? http://en.wikipedia.org/wiki/Cipher_block_chaining -jb -- Real computer scientists don't comment their code. The identifiers are so long they can't afford the disk space. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- thanks, Lakshmi Prasanna __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Difference in packet contents
Yup, that solves it. Another matter that's been troubling me is the output that I get when I run the s_server program with the debug option. At the end of the handshake, when the server sends the Finished Packet to the client, the following packet dump is obtained. write to 099EB570 [099FADC0] (53 bytes = 53 (0x35)) - 16 03 01 00 30 b8 bd 82-61 05 3c 59 0e 0e cc 0b 0010 - 57 88 ad f2 93 1e 5a 1f -9f d1 82 3a 10 e2 4b d3 0020 - 00 f4 91 7d f1 10 a2 1d-d4 e6 ef 2a c6 be 1e b5 0030 - 16 fd f6 09 71 Byte 0x00 - 0x16 is indicative of the Handshake protocol in progress. Byte 0x01 and 0x02 - SSL v.3.1 Byte 0x03 and 0x04 - Length of message that follows, 48 bytes + the 5 before it, totals to the 53 bytes shown at the very beginning. Byte 0x05 - This is where the trouble begins. It shows 0xb8 which does not correspond to any standard message type. It should, in my opinion show, 0x14 which is the message type for the Finished packet. I ran the same program a few times I keep getting what appears to me as random bytes each time. When I run the s_server program with both the msg and debug options, the output from the msg tallies with my observation above. I was not sure if the actual packet contents that were being sent as both the msg and debug option seemed to contradict each other. I then wrote a sniffer to check the actual packet contents and they corresponded to those received from debug mode which now leads to me believe this - That, in the Finish packet, the message type, message length and the handshake message are all encrypted. Am I right in thinking so? In which case, I wonder, if the client were to receive such a packet, which coincedentally were to have its Byte 0x05 as some standard message type, will it not proceed to treat that packet correspondingly instead of treating it as a Finished packet? Taking this even further, the whole idea of having 20 as a standard message type for a finished packet would be useless. I realise that the above is a pretty lengthy description of the problem that I am facing and will be more than happy to elaborate on any part of it that is ambigous. I am obviously wrong somewhere and it would be great if someone can point where exactly. Thanks a lot, Vijay K. On Tue, Jun 17, 2008 at 4:53 PM, lakshmi prasanna [EMAIL PROTECTED] wrote: Hi, Actually, AES is by default implemented in CBC (Cipher Block Chaining )mode in TLSv1. Refer RFC 3268. Since the encryption is done in CBC mode, you will not get the same encrypted text for identical plain text. --lakshmi prasanna On Tue, Jun 17, 2008 at 10:58 AM, jimmy bahuleyan [EMAIL PROTECTED] wrote: Vijay Kotari wrote: @DS Nicely put. So, if I was to try to decrypt/encrypt one of these messages, I would need the key and the iv and something else? Because if just the key and iv are sufficient to encrypt/decrypt the data, then how are the different encrypted messages generated for the same cleartext? http://en.wikipedia.org/wiki/Cipher_block_chaining -jb -- Real computer scientists don't comment their code. The identifiers are so long they can't afford the disk space. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- thanks, Lakshmi Prasanna __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
cannot use some parameters for enc
(sorry for my english) Hi all. I'd like to test latest sources from cvs with russian gost algorithm, but I cannot for example use openssl enc -gost89, programm tells me then, no such parameter. And another question: I'd like to test openvpn+openssl with russian cipher algorithm to crypt traffic between 2 servers, but I cannot see any GOST algorithm. -- Software is like sex, it is better when it's free
Server Name Indication usage in OpenSSL 0.9.8g
Hi, I am developing a server application that have to process SNI coming from the connecting clients. I found here: http://weblogs.mozillazine.org/gerv/archives/2007/08/virtual_hosting_ssl_and_sni.html that there is a backport available for 0.9.8 version that should be configured with tls-ext. Unfortunately, I can't find any documentation about how to use this SNI feature in the code. Is there any description (or at least the name) of the functions of openssl that I can use to access SNI field of TLS hello message?. Did anybody already use those functions? Any help is very much appreciated. Thanks in advance. -- Sergey Gerasimenko -- View this message in context: http://www.nabble.com/Server-Name-Indication-usage-in-OpenSSL-0.9.8g-tp17896727p17896727.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 [EMAIL PROTECTED]
Re: Difference in packet contents
Hi, Actually, the Handshake Message becomes the data for record protocol. so the Handshake message for Finished message contains a header that has 20 in the type field to indicate Finished message. This Handshake message including the Header and Data, is encrypted using the keys generated during negotiation. I think that's the reason why, after the Record protocol Header data (5 bytes) nothing makes sense as it is encrypted. --Lakshmi Prasanna On Tue, Jun 17, 2008 at 5:41 PM, Vijay Kotari [EMAIL PROTECTED] wrote: Yup, that solves it. Another matter that's been troubling me is the output that I get when I run the s_server program with the debug option. At the end of the handshake, when the server sends the Finished Packet to the client, the following packet dump is obtained. write to 099EB570 [099FADC0] (53 bytes = 53 (0x35)) - 16 03 01 00 30 b8 bd 82-61 05 3c 59 0e 0e cc 0b 0010 - 57 88 ad f2 93 1e 5a 1f -9f d1 82 3a 10 e2 4b d3 0020 - 00 f4 91 7d f1 10 a2 1d-d4 e6 ef 2a c6 be 1e b5 0030 - 16 fd f6 09 71 Byte 0x00 - 0x16 is indicative of the Handshake protocol in progress. Byte 0x01 and 0x02 - SSL v.3.1 Byte 0x03 and 0x04 - Length of message that follows, 48 bytes + the 5 before it, totals to the 53 bytes shown at the very beginning. Byte 0x05 - This is where the trouble begins. It shows 0xb8 which does not correspond to any standard message type. It should, in my opinion show, 0x14 which is the message type for the Finished packet. I ran the same program a few times I keep getting what appears to me as random bytes each time. When I run the s_server program with both the msg and debug options, the output from the msg tallies with my observation above. I was not sure if the actual packet contents that were being sent as both the msg and debug option seemed to contradict each other. I then wrote a sniffer to check the actual packet contents and they corresponded to those received from debug mode which now leads to me believe this - That, in the Finish packet, the message type, message length and the handshake message are all encrypted. Am I right in thinking so? In which case, I wonder, if the client were to receive such a packet, which coincedentally were to have its Byte 0x05 as some standard message type, will it not proceed to treat that packet correspondingly instead of treating it as a Finished packet? Taking this even further, the whole idea of having 20 as a standard message type for a finished packet would be useless. I realise that the above is a pretty lengthy description of the problem that I am facing and will be more than happy to elaborate on any part of it that is ambigous. I am obviously wrong somewhere and it would be great if someone can point where exactly. Thanks a lot, Vijay K. On Tue, Jun 17, 2008 at 4:53 PM, lakshmi prasanna [EMAIL PROTECTED] wrote: Hi, Actually, AES is by default implemented in CBC (Cipher Block Chaining )mode in TLSv1. Refer RFC 3268. Since the encryption is done in CBC mode, you will not get the same encrypted text for identical plain text. --lakshmi prasanna On Tue, Jun 17, 2008 at 10:58 AM, jimmy bahuleyan [EMAIL PROTECTED] wrote: Vijay Kotari wrote: @DS Nicely put. So, if I was to try to decrypt/encrypt one of these messages, I would need the key and the iv and something else? Because if just the key and iv are sufficient to encrypt/decrypt the data, then how are the different encrypted messages generated for the same cleartext? http://en.wikipedia.org/wiki/Cipher_block_chaining -jb -- Real computer scientists don't comment their code. The identifiers are so long they can't afford the disk space. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- thanks, Lakshmi Prasanna __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- thanks, Lakshmi Prasanna __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Difference in packet contents
Hello, [EMAIL PROTECTED] wrote on 06/17/2008 02:11:14 PM: Yup, that solves it. Another matter that's been troubling me is the output that I get when I run the s_server program with the debug option. At the end of the handshake, when the server sends the Finished Packet to the client, the following packet dump is obtained. write to 099EB570 [099FADC0] (53 bytes = 53 (0x35)) - 16 03 01 00 30 b8 bd 82-61 05 3c 59 0e 0e cc 0b 0010 - 57 88 ad f2 93 1e 5a 1f -9f d1 82 3a 10 e2 4b d3 0020 - 00 f4 91 7d f1 10 a2 1d-d4 e6 ef 2a c6 be 1e b5 0030 - 16 fd f6 09 71 Byte 0x00 - 0x16 is indicative of the Handshake protocol in progress. Byte 0x01 and 0x02 - SSL v.3.1 Byte 0x03 and 0x04 - Length of message that follows, 48 bytes + the 5 before it, totals to the 53 bytes shown at the very beginning. Byte 0x05 - This is where the trouble begins. It shows 0xb8 which does not correspond to any standard message type. It should, in my opinion show, 0x14 which is the message type for the Finished packet. I ran the same program a few times I keep getting what appears to me as random bytes each time. When I run the s_server program with both the msg and debug options, the output from the msg tallies with my observation above. I was not sure if the actual packet contents that were being sent as both the msg and debug option seemed to contradict each other. I then wrote a sniffer to check the actual packet contents and they corresponded to those received from debug mode which now leads to me believe this - That, in the Finish packet, the message type, message length and the handshake message are all encrypted. Am I right in thinking so? In which case, I wonder, if the client were to receive such a packet, which coincedentally were to have its Byte 0x05 as some standard message type, will it not proceed to treat that packet correspondingly instead of treating it as a Finished packet? Taking this even further, the whole idea of having 20 as a standard message type for a finished packet would be useless. I realise that the above is a pretty lengthy description of the problem that I am facing and will be more than happy to elaborate on any part of it that is ambigous. I am obviously wrong somewhere and it would be great if someone can point where exactly. Finished packet is the first packet with encrypted contents. If you look at packets dump, you will see ChangeCipherSpec packet Finished packet. All packet after ChangeCipherSpec should use encryption, this is something like switch witch turn on encryption. So, Finished packet should be decrypted before analysed. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Difference in packet contents
Hi,
I do know for a fact that part of the Finish message is encrypted. My
question was actually if the Message type field is also part of the
encrypted part? In which case, as I had pointed out earlier, there is a
chance that the first byte of the encrypted {message_type + message} can be
equal to one of the Standard Message types hence misleading the client to
the type of packet that is actually being sent. To put it another way, IMHO,
it does not make sense to have a field in a packet whose value does not give
us any information of the packet itself. i.e. if the field contains 14 (in
base 10), should it be interpreted as a Finish packet with encrypted data
whose first byte also happens to be 14 or a ServerHelloDone packet?
Regards,
Vijay K.
On Tue, Jun 17, 2008 at 6:32 PM, [EMAIL PROTECTED] wrote:
Hello,
[EMAIL PROTECTED] wrote on 06/17/2008 02:11:14 PM:
Yup, that solves it.
Another matter that's been troubling me is the output that I get when I
run the s_server
program with the debug option. At the end of the handshake, when the
server sends the
Finished Packet to the client, the following packet dump is obtained.
write to 099EB570 [099FADC0] (53 bytes = 53 (0x35))
- 16 03 01 00 30 b8 bd 82-61 05 3c 59 0e 0e cc 0b
0010 - 57 88 ad f2 93 1e 5a 1f -9f d1 82 3a 10 e2 4b d3
0020 - 00 f4 91 7d f1 10 a2 1d-d4 e6 ef 2a c6 be 1e b5
0030 - 16 fd f6 09 71
Byte 0x00 - 0x16 is indicative of the Handshake protocol in progress.
Byte 0x01 and 0x02 - SSL v.3.1
Byte 0x03 and 0x04 - Length of message that follows, 48 bytes + the 5
before it, totals
to the 53 bytes shown at the very beginning.
Byte 0x05 - This is where the trouble begins. It shows 0xb8 which does
not correspond
to any standard message type. It should, in my opinion show, 0x14 which
is the message
type for the Finished packet. I ran the same program a few times I keep
getting what
appears to me as random bytes each time. When I run the s_server program
with both the
msg and debug options, the output from the msg tallies with my
observation above. I was
not sure if the actual packet contents that were being sent as both the
msg and debug
option seemed to contradict each other.
I then wrote a sniffer to check the actual packet contents and they
corresponded to
those received from debug mode which now leads to me believe this -
That, in the
Finish packet, the message type, message length and the handshake
message are all
encrypted. Am I right in thinking so? In which case, I wonder, if the
client were to
receive such a packet, which coincedentally were to have its Byte 0x05
as some standard
message type, will it not proceed to treat that packet correspondingly
instead of
treating it as a Finished packet? Taking this even further, the whole
idea of having 20
as a standard message type for a finished packet would be useless.
I realise that the above is a pretty lengthy description of the problem
that I am facing
and will be more than happy to elaborate on any part of it that is
ambigous. I am
obviously wrong somewhere and it would be great if someone can point
where exactly.
Finished packet is the first packet with encrypted contents.
If you look at packets dump, you will see ChangeCipherSpec packet Finished
packet.
All packet after ChangeCipherSpec should use encryption, this is something
like switch witch turn on encryption.
So, Finished packet should be decrypted before analysed.
Best regards,
--
Marek Marcola [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: getting certificate from X509_STORE
Same problem. I wanted to know where is stocked the Server certificate during the SSL/TLS communication. For example I have my client who connect to a web service using SSL/TLS. I wanted that my client get the certificate used by the server to get his name. Is it possible? Thanks, Maxime. 2008/6/14 Kah Goh [EMAIL PROTECTED]: Hi, I had a look at X509_STORE_CTX_init and I agree that it looks like it might cause seg fault, although I think it is unlikely. But first, may I ask, what makes you think it comes from X509_STORE_CTX_init? Was it from a core dump? It is possible for X509_get _issuer_name to cause segmentation fault as well. Other comments: - Use SSL_CTX_get_cert_store(ctx) to get the X509_STORE from SSL_CTX instead. - X509_name_oneline is discouraged, according to the documentation. This is a minor thing though... --- Kah 2008/6/13 BRACHET Maxime [EMAIL PROTECTED]: Hi, Yes, I tried something like this : char data[256]; SSL_CTX *context = (soap)-ctx; X509_STORE *store = context-cert_store; X509_STORE_CTX xs_ctx; X509_STORE_CTX_init(xs_ctx,store,NULL,NULL); X509 *cert = X509_STORE_CTX_get_current_cert(xs_ctx); fprintf(stderr, SSL verify error or warning with certificate at depth %d: %s\n, X509_STORE_CTX_get_error_depth(xs_ctx), X509_verify_cert_error_string(X509_STORE_CTX_get_error(xs_ctx))); X509_NAME_oneline(X509_get_issuer_name(cert), data, sizeof(data)); but It give me a segmentation fault error. I think it come from that the X509_STORE_CTX_init take in parameter a X509 certificate, the one I want to get . any other idea ? Thanks, Maxime. 2008/6/13 Klarth [EMAIL PROTECTED]: Hi I think you want to use X509_STORE_CTX_init to put the X509_STORE in X509_STORE_CTX. --- Kah On Jun 13, 3:36 pm, [EMAIL PROTECTED] (BRACHET Maxime) wrote: Hi, I am using gSOAP which use openssl. I establish a connexion to a server using TLS, and I wanted to get the Name of the Server certificate. I can access to a X509_STORE trough ctx-cert_store. But I don't find how to get the Server certificate. I found the X509_STORE_CTX_get_current_cert(store) method, but to use it I need a X509_STORE_CTX. Is it possible to get a X509_STORE_CTX from a X509_STORE ? Thanks in advance. Regards, Maixme
Re: Difference in packet contents
The whole Finish message, (ie., Handshake protocols Header indicating
this message as Finished message, and the encrypted Data) is encrypted
and sent.
At the other end the packet is decrypted. This decryption is done
because a Change Cipher Spec message has been received before this
message by the other end.
After decrypting the received message, it finds the expected Finished
message, and verifies the data sent in the Finished message.
-- Lakshmi Prasanna
On Tue, Jun 17, 2008 at 6:51 PM, Vijay Kotari [EMAIL PROTECTED] wrote:
Hi,
I do know for a fact that part of the Finish message is encrypted. My
question was actually if the Message type field is also part of the
encrypted part? In which case, as I had pointed out earlier, there is a
chance that the first byte of the encrypted {message_type + message} can be
equal to one of the Standard Message types hence misleading the client to
the type of packet that is actually being sent. To put it another way, IMHO,
it does not make sense to have a field in a packet whose value does not give
us any information of the packet itself. i.e. if the field contains 14 (in
base 10), should it be interpreted as a Finish packet with encrypted data
whose first byte also happens to be 14 or a ServerHelloDone packet?
Regards,
Vijay K.
On Tue, Jun 17, 2008 at 6:32 PM, [EMAIL PROTECTED] wrote:
Hello,
[EMAIL PROTECTED] wrote on 06/17/2008 02:11:14 PM:
Yup, that solves it.
Another matter that's been troubling me is the output that I get when I
run the s_server
program with the debug option. At the end of the handshake, when the
server sends the
Finished Packet to the client, the following packet dump is obtained.
write to 099EB570 [099FADC0] (53 bytes = 53 (0x35))
- 16 03 01 00 30 b8 bd 82-61 05 3c 59 0e 0e cc 0b
0010 - 57 88 ad f2 93 1e 5a 1f -9f d1 82 3a 10 e2 4b d3
0020 - 00 f4 91 7d f1 10 a2 1d-d4 e6 ef 2a c6 be 1e b5
0030 - 16 fd f6 09 71
Byte 0x00 - 0x16 is indicative of the Handshake protocol in progress.
Byte 0x01 and 0x02 - SSL v.3.1
Byte 0x03 and 0x04 - Length of message that follows, 48 bytes + the 5
before it, totals
to the 53 bytes shown at the very beginning.
Byte 0x05 - This is where the trouble begins. It shows 0xb8 which does
not correspond
to any standard message type. It should, in my opinion show, 0x14 which
is the message
type for the Finished packet. I ran the same program a few times I keep
getting what
appears to me as random bytes each time. When I run the s_server program
with both the
msg and debug options, the output from the msg tallies with my
observation above. I was
not sure if the actual packet contents that were being sent as both the
msg and debug
option seemed to contradict each other.
I then wrote a sniffer to check the actual packet contents and they
corresponded to
those received from debug mode which now leads to me believe this -
That, in the
Finish packet, the message type, message length and the handshake
message are all
encrypted. Am I right in thinking so? In which case, I wonder, if the
client were to
receive such a packet, which coincedentally were to have its Byte 0x05
as some standard
message type, will it not proceed to treat that packet correspondingly
instead of
treating it as a Finished packet? Taking this even further, the whole
idea of having 20
as a standard message type for a finished packet would be useless.
I realise that the above is a pretty lengthy description of the problem
that I am facing
and will be more than happy to elaborate on any part of it that is
ambigous. I am
obviously wrong somewhere and it would be great if someone can point
where exactly.
Finished packet is the first packet with encrypted contents.
If you look at packets dump, you will see ChangeCipherSpec packet Finished
packet.
All packet after ChangeCipherSpec should use encryption, this is something
like switch witch turn on encryption.
So, Finished packet should be decrypted before analysed.
Best regards,
--
Marek Marcola [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
--
thanks,
Lakshmi Prasanna
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Difference in packet contents
Hello,
[EMAIL PROTECTED] wrote on 06/17/2008 03:21:08 PM:
Hi,
I do know for a fact that part of the Finish message is encrypted. My
question was
actually if the Message type field is also part of the encrypted part?
In which case, as
I had pointed out earlier, there is a chance that the first byte of the
encrypted
{message_type + message} can be equal to one of the Standard Message
types hence
misleading the client to the type of packet that is actually being sent.
To put it
another way, IMHO, it does not make sense to have a field in a packet
whose value does
not give us any information of the packet itself. i.e. if the field
contains 14 (in base
10), should it be interpreted as a Finish packet with encrypted data
whose first byte
also happens to be 14 or a ServerHelloDone packet?
Finished packet is built with:
Protcol header:
---
22 - protocol (1 byte)
3- ssl/tls wersion (2 bytes, this and next)
0/1
len1 - data length (2 bytes, this and next)
len2
Handshake header:
-
20 - type
hs_len1 - handhsake data length (3 bytes, this and next two)
hs_len2
hs_len3
Handshake data:
---
signed digest1 - MD5 for RSA
signed digest2 - SHA1 for RSA,DSA
SSL/TLS is built with layers, encryption is used ad record layer
where handshake layer and data layer are above this layer.
From record layer point of view there is not difference between
application data and handshake packet, all is encrypted and send
to other party or decrypted and send to layer above.
There is only one sign of type of data sent: first byte
which tells what kind of data is carried by packet but this is
used to defend against reply attacks too (this byte is used in MAC
calculation).
So, in case of Finised packet, record layer puts handshake header and
data,
add MAC and PAD, encrypt this, encapsulate encrypted data with 5 byte
protocol header and sent to peer:
protocol_header, {handshake_header,handshake_data,MAC,PAD}
^^ ENCRYPTED
Best regards,
--
Marek Marcola [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
How to extract subjectAltName
Hi,
I try to read subjectAltName, but ASN1_STRING_to_UTF8 seems not to work.
For the X509_NAME entries the same procedure works,
but this ASN1_STRING seems to be different.
In the debugger I can already see the ASN1_STRING:
pString-length = 43
pString-type = 4
pString-data = 0)† urn:x:bla‚ xxx
pString-flags = 0
Code snippet:
UaPkiCertificateInfo UaPkiCertificate::info() const
{
UaPkiCertificateInfo ret;
X509_EXTENSION *pExt;
char *pBuffer = 0;
int length = 0;
int loc = X509_get_ext_by_NID(m_pCert, NID_subject_alt_name, -1);
pExt = X509_get_ext(m_pCert, loc);
if (pExt)
{
ASN1_STRING *pString = X509_EXTENSION_get_data(pExt);
length = ASN1_STRING_to_UTF8((unsigned char**)pBuffer, pString);
ret.subjectAltName = pBuffer;
OPENSSL_free(pBuffer);
}
return ret;
}
regards,
Gerhard
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Please help: very urgent: Query on patented algorithms
At 01:20 PM 6/16/2008, Michael Sierchio wrote: RC4 is owned (and trademarked) by RSA Security Inc, but they are no longer enforcing the patent, RC4 was never protected by patent, but by trade secret. When the details of the algorithm were published, Ron Rivest himself suggested calling the alleged RC4 ARCFOUR. It is indeed a trademark of RSA Security. Michael is right. No patent. RSA subsequently switched to patent protection for RC5 and RC5. Some ancient history might offer context. RC4, developed by Rivest in 1987, was originally sold, under contractual constraints, as a proprietary RSA trade secret -- a mode of IP protection which soon proved to be frail and toothless in Cyberspace, where anonymous publication on the Net broke the trade secret contract but allowed the perpetrator to escape all liability. RSADSI initially filed for US trademark protection on RC4 in 1993, and the trademark -- as a mark of origin, a mark that identified the source of the distributed code -- became the last line defense for the RC4 IP when the RC4 algorithm was reverse engineered and published on the Cypherpunks List in September of 1994. In a swirl of ironies, this was a critical event in public crypto history, because the illicit publication of RC4 made it possible for non-US developers to do their own versions of SSL. SSLea, ancestor of OpenSSL, soon broke the NSA's restrictive policies on the international use of strong-crypto SSL for browsers and web-based transactions. Many versions of alleged RC4 (ARC4 or ArcFour) were soon in widespread use, even in IETF standards. Anyone can code or use ACR4, but EMC/RSA still defends its monopoly on the RC4 trademark because undefended trademarks become invalid. _Vin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: How to load a chain of certificates ?
delcour.pierre wrote: Hello, Ariel Salomon wrote: Hi Pierre, If you are using this certificate chain for an SSL connection, use SSL_CTX_use_certificate_chain_file which does precisely what you are asking. If you are just looking for a way to load this chain for other uses, the source code for that function should help you out. take a look at the man page: http://www.openssl.org/docs/ssl/SSL_CTX_use_certificate.html - Ariel delcour.pierre wrote: Hello everyone, I have to load a chain of x509v3 certificates which is only one file, like this one (i cut it): -BEGIN CERTIFICATE- MIIEjjC[...]7DjKlgcOcx -END CERTIFICATE- -BEGIN CERTIFICATE- MIIEfzC[...]ds0pfH -END CERTIFICATE- -BEGIN CERTIFICATE- MIIEeT[...]AxQv6oN -END CERTIFICATE- -BEGIN CERTIFICATE- MIIEdjC[...]1zwDx -END CERTIFICATE- -BEGIN CERTIFICATE- MIIEcjC[...]WziILI= -END CERTIFICATE- So, how can i load it thanks to openssl ? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] Thank's for your answer. I took a look at this page, and i wrote this code : SSL_CTX *ctx = NULL; ctx = SSL_CTX_new(SSLv23_method()); cout SSL_CTX_use_certificate_chain_file(ctx, /home/pierred/chain/cert.chain.pem) endl; I only got a segmentation fault. After looking at the source code of the SSL_CTX_use_certificate_chain_file, i found that the seg. fault is due to this line : ret=SSL_CTX_use_certificate(ctx,x); I thought, i have to use another function instead of this one SSLv23_method(). I try SSLv3_method(), but no change. I 'm using openssl 0.9.8g on kubuntu 8.04. Thank's in advance, pierre delcour. Hello, I still looking for a solution of this problem... Thank's in advance pierre delcour
FIPS build errors with openssl-0.9.7m
Greetings, I have followed the procedures for MinGW/Msys/VC build for Windows described here: http://www.oss-institute.org/FIPS_733/UserGuide-1.1.1.pdf and everything worked fines up to this step: Nmake -f ms\ntdll.mak I get this error message: LINK : fatal error LNK1000: Internal error during BuildImage I have tried VC6, VC7, VC8 with nearly exactly the same message in the same place. The build of static libraries worked fine. Any ideas? Regards, Luke R. Batko
Re: How to extract subjectAltName
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gerhard Gappmeier wrote:
| Hi,
Hello Gerhard,
| I try to read subjectAltName, but ASN1_STRING_to_UTF8 seems not to work.
| For the X509_NAME entries the same procedure works,
| but this ASN1_STRING seems to be different.
That is because only in the simple cases the extension data directly
contains the readable extension.
But the subjectAltName has the type GeneralNames
and GeneralNames is a sequence of GeneralName
So the way to decode a subjectAltName extension is to
use the X509_get_ext_d2i() function:
GeneralNames *names;
STACK_OF(CONF_VALUE) *vals = sk_CONV_VALUE_new_null();
names = X509_get_ext_d2i(cert, NID_subject_alt_name, NULL, NULL);
if (names) {
/* you now can use OpenSSL to transform the names into
some printable format... */
i2v_GENERAL_NAMES(NULL, names, vals);
sk_GENERAL_NAME_pop_free(names, GENERAL_NAME_free);
}
for(int i = 0; i sk_CONF_VALUE_num(vals); i++) {
CONF_VALUE *conf = sk_CONF_VALUE_value(vals, i);
ret.subjectAltName.appendNameValue(conf-name, conf-value);
}
sk_CONF_VALUE_pop_free(vals, CONF_VALUE_free);
The following subject alt names can not be fetched because OpenSSL
can not display them:
~ * otherName
~ * x400Address
~ * ediParityName
The following values are simple text because they are of type ia5String:
~ * rfc822Name
~ * dNSName
~ * uniformResourceIdentifier
Type ipAddress is also printed as simple text
The type registeredID is also simple text.
The type directoryName may have conversion errors (I didn't check).
If you really need otherName, x400Adress or ediParityName,
you have to implement their conversion methods on your own.
For hints how to convert a GENERAL_NAME into something printable,
crypto/x509v3/v3_alt.c is a starter...
Goetz
- --
DMCA: The greed of the few outweighs the freedom of the many
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIWDMK2iGqZUF3qPYRAmd5AJ4yh6NCZc3y89cejyS7MNmbD0CcegCfVWiJ
FB3k+Q1He7JZ/kSPaoRMivk=
=3oUz
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Removal from mailing list
Hi. I'd like to get myself removed from the mailing list. What do I do? Thanks, Dan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Gregoire LECOMTE is out of the office.
I will be out of the office starting 18/06/2008 and will not return until 24/06/2008. - Support : Call Notes support team (34949) - Projects : Contact Nabil JAAFOURA. Regards * This message and any attachments (the message) are confidential, intended solely for the addressee(s), and may contain legally privileged information. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. Ce message et toutes les pieces jointes (ci-apres le message) sont confidentiels et susceptibles de contenir des informations couvertes par le secret professionnel. Ce message est etabli a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. La SOCIETE GENERALE et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. * __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: cannot use some parameters for enc
You should visit developers site at http://www.cryptocom.ru/OpenSource/OpenSSL_rus.html (English version http://www.cryptocom.ru/OpenSource/OpenSSL_eng.html) You can find all information about GOST in OpenSSL there. Alexey Eropkin пишет: (sorry for my english) Hi all. I'd like to test latest sources from cvs with russian gost algorithm, but I cannot for example use openssl enc -gost89, programm tells me then, no such parameter. And another question: I'd like to test openvpn+openssl with russian cipher algorithm to crypt traffic between 2 servers, but I cannot see any GOST algorithm. -- С уважением, Андрей Кольцов программист ОАО Киберплат тел: (495) 981-80-80 доб. 3031 (495) 967-02-20 доб. 3031 e-mail: [EMAIL PROTECTED] site: www.cyberplat.ru __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
