Re: Certificate chain question
Here the rootCA signs both myside.com and part.myside.com. So the certificate chain is as I understand as follows rootCA --- signs - myside.com rootCA --- signs - part.myside.com So, this above scenario would necessiate only rootCA to verify part.myside.com. It doesn't need myside.com since myside.com does not sign part.myside.com. If you have an intermediate CA to sign part.myside.com for ex rootCA ---signs--- intermediate CA signs part.myside.com then one has to add intermediate CA also to verify part.myside.com.So may be you have missed out on the intermediate CA as Dr.Stephen suggested cheers and if you solve it pls let me know Pjothi On 2/13/06, Gayathri Sundar [EMAIL PROTECTED] wrote: I think you should load myside.com as well onto the browser.. as it is needed to verify part.myside.com. Thanks --G3 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Zaid Sent: Sunday, February 12, 2006 5:33 AM To: openssl-users@openssl.org Subject: Certificate chain question I have a root CA which is loaded on my browser, the rootCA certify mysite.com which is also used to certify part.mysite.com when user go directly to part.mysite.com the browser complains because the certifcate chain is not complete. Has anyone experienced this problem or can perhaps explain why this would happen? Thanks, Zaid ++++ If we don't believe in freedom of expression for people we despise, we don't believe in it at all. Chomsky, Noam Zaid's Blog: http://drummergeek.blogspot.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: SSL_shutdown and SIGPIPE
yeah, I have an unusual requirement dat, I cant ignore sigpipe.. meanwhile, SSL_get_shutdown will check the FD status, and if a FIN/RST was received, the return value will reflect dat..so I will not even attempt a write. Thanks --G3 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Kyle Hamilton Sent: Monday, February 13, 2006 11:15 AM To: openssl-users@openssl.org Subject: Re: SSL_shutdown and SIGPIPE Why are you trying to avoid SIGPIPE, anyway? It's easy to ignore, and a global state would make it possible to determine what socket you were writing on (if you needed that). -Kyle H On 2/12/06, Gayathri Sundar [EMAIL PROTECTED] wrote: Probably you can call the following iRet = SSL_get_shutdown(pSSL); if(iRet = 0) SSL_shutdown(pSSL); This is because, SSL_shutdown writes data on the wire, i.e the closure alerts..and if a FIN was received meanwhile, you will catch a SIGPIPE..this piece of code, actually saves me from this.. Thanks --G3 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alberto Alonso Sent: Sunday, February 12, 2006 2:08 PM To: openssl-users@openssl.org Subject: SSL_shutdown and SIGPIPE I am getting SIGPIPE signals under Linux when calling on SSL_shutdown and the remote is gone. Basically, the remote end terminates the connection abruptly, then the server finishes doing whatever is doing and issues a SSL_shutdown on the ssl structure that used to handle the connection. This generates a SIGPIPE on the server. Is there anything I should be checking for before calling SSL_shutdown to make sure the connection is still OK? Thanks, Alberto -- Alberto AlonsoGlobal Gate Systems LLC. (512) 351-7233http://www.ggsys.net Hardware, consulting, sysadmin, monitoring and remote backups __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL_shutdown and SIGPIPE
SIGPIPE is a remnant of BSD attempting to overlay UNIX socket (named
pipe) semantics onto TCP/IP connections. If the socket that you are
writing to is a socket (or pipe), AND the pipe is closed, then you
receive a SIGPIPE.
In this case, the 'good reason' for it is that what you think is
supposed to be listening isn't listening anymore, so you may need to
update your internal state. However, since the other effect of
writing to a socket that is remote-closed is the descriptor itself
being closed, there's no reason to worry about it.
I help maintain a MUD software (that uses OpenSSL); often players will
disconnect by closing their clients instead of using the QUIT command,
and this leads to attempts to send information to them. When the
software receives the TCP RST ('connection reset by peer'), it also
receives a SIGPIPE. However, we have no need to deal with it, since
we check the return status of the write operation; if it fails, we
close the socket and clean up the memory allocated to that connection.
On 2/12/06, Alberto Alonso [EMAIL PROTECTED] wrote:
I personally don't know why pipes are even in use in the openssl
internals (though I bet there is a good reason for it :-)
It's there because the underlying operating system forces them to be
there. It's certainly not at the behest of the OpenSSL team.
Ignoring SIGPIPE (or most signals for that matter) is not really
that good. They get generated for good reasons.
...explained above...
In my case, depending on what came down the wire, I have to interact
with other utilities in the system, therefore opening pipes. I need
to make sure I get the signals when a system tool exits unexpectedly.
Alright, then just check to see what descriptor actually caused the
SIGPIPE (instead of setting it to SIG_IGN, you always have the ability
to write your own handler). If it's a descriptor that connects to
another utility, handle that special case (preferably by setting a
global variable and exiting the signal handler quickly, before
handling the exceptional circumstance in your main program loop --
this is akin to a 'deferred procedure call' in Windows 2000+ device
driver programming). If it's not, then it probably belongs to a
TLS/SSL connection, and can be safely ignored (since you're supposed
to be checking the return statuses of all of your OpenSSL calls
anyway, and since you're trying to shut down the SSL socket, you might
as well just call SSL_free() immediately after the SSL_shutdown
[taking into account the possibility of an SSL_WANTS_WRITE return
status].
-Kyle H
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Is configuration without sockets possible?
Hi list, We are developing an embedded device where there are no sockets. We have other communication media, though, like radio signals, for which we need authentication/encryption, and OpenSSL is an obvious choice for that. Now, my question: Is configuration of OpenSSL without sockets possible? If so, how? If not, is there an easy way for me to factor them out by hand? Thanks, Rutger Hofman VU Amsterdam __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Is configuration without sockets possible?
Hi! One way is to use bio_pairs. There is an example of bio_pair usage in 'ssl_test.c' file in the OpenSSL package. Hope this helps, Regards, Usman. From: Rutger Hofman [EMAIL PROTECTED] Reply-To: openssl-users@openssl.org To: openssl-users@openssl.org Subject: Is configuration without sockets possible? Date: Mon, 13 Feb 2006 16:10:56 +0100 MIME-Version: 1.0 X-Sender: Rutger Hofman [EMAIL PROTECTED] Received: from mmx1.engelschall.com ([195.30.6.154]) by bay0-mc12-f13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Feb 2006 07:12:30 -0800 Received: by mmx1.engelschall.com (Postfix)id 0395A5643B; Mon, 13 Feb 2006 16:11:01 +0100 (CET) Received: from master.openssl.org (master.openssl.org [195.30.6.166])by mmx1.engelschall.com (Postfix) with ESMTP id EA3EE5643Afor [EMAIL PROTECTED]; Mon, 13 Feb 2006 16:11:00 +0100 (CET) Received: by master.openssl.org (Postfix)id 263651AC64B9; Mon, 13 Feb 2006 16:11:00 +0100 (CET) Received: by master.openssl.org (Postfix, from userid 29101)id 2445E1AC649D; Mon, 13 Feb 2006 16:11:00 +0100 (CET) Received: from flits.few.vu.nl (flits.few.vu.nl [192.31.231.65])by master.openssl.org (Postfix) with ESMTP id 04CA01AC64B7for openssl-users@openssl.org; Mon, 13 Feb 2006 16:10:58 +0100 (CET) Received: from cs.vu.nl (mercury.cs.vu.nl [130.37.193.14])by flits.few.vu.nl with esmtp (Smail #108)id m1F8fLs-00024SC; Mon, 13 Feb 2006 16:10 +0100 X-Message-Info: v3EOnANkQL1DX/OLuxzxm+nFJtdJr3McCTYzkCwgCT0= Delivered-To: openssl-users-l@master.openssl.org X-Original-To: openssl-users@openssl.org Delivered-To: openssl-users@openssl.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en Precedence: bulk X-List-Manager: OpenSSL Majordomo [version 1.94.5] X-List-Name: openssl-users Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 13 Feb 2006 15:12:31.0254 (UTC) FILETIME=[E8F6DB60:01C630AF] Hi list, We are developing an embedded device where there are no sockets. We have other communication media, though, like radio signals, for which we need authentication/encryption, and OpenSSL is an obvious choice for that. Now, my question: Is configuration of OpenSSL without sockets possible? If so, how? If not, is there an easy way for me to factor them out by hand? Thanks, Rutger Hofman VU Amsterdam __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL_shutdown and SIGPIPE
None of the solutions suggested by others in the list
will protect you against a SIGPIPE for the simple
reason that it is a fatal signal if not handled or
ignored and it can come at any time during the TCP
session...
Ignoring SIGPIPE is one of the steps in writing a
server daemon and it is standard practice.
Best,
Girish
--- Kyle Hamilton [EMAIL PROTECTED] wrote:
SIGPIPE is a remnant of BSD attempting to overlay
UNIX socket (named
pipe) semantics onto TCP/IP connections. If the
socket that you are
writing to is a socket (or pipe), AND the pipe is
closed, then you
receive a SIGPIPE.
In this case, the 'good reason' for it is that what
you think is
supposed to be listening isn't listening anymore, so
you may need to
update your internal state. However, since the
other effect of
writing to a socket that is remote-closed is the
descriptor itself
being closed, there's no reason to worry about it.
I help maintain a MUD software (that uses OpenSSL);
often players will
disconnect by closing their clients instead of using
the QUIT command,
and this leads to attempts to send information to
them. When the
software receives the TCP RST ('connection reset by
peer'), it also
receives a SIGPIPE. However, we have no need to
deal with it, since
we check the return status of the write operation;
if it fails, we
close the socket and clean up the memory allocated
to that connection.
On 2/12/06, Alberto Alonso [EMAIL PROTECTED]
wrote:
I personally don't know why pipes are even in use
in the openssl
internals (though I bet there is a good reason for
it :-)
It's there because the underlying operating system
forces them to be
there. It's certainly not at the behest of the
OpenSSL team.
Ignoring SIGPIPE (or most signals for that matter)
is not really
that good. They get generated for good reasons.
...explained above...
In my case, depending on what came down the wire,
I have to interact
with other utilities in the system, therefore
opening pipes. I need
to make sure I get the signals when a system tool
exits unexpectedly.
Alright, then just check to see what descriptor
actually caused the
SIGPIPE (instead of setting it to SIG_IGN, you
always have the ability
to write your own handler). If it's a descriptor
that connects to
another utility, handle that special case
(preferably by setting a
global variable and exiting the signal handler
quickly, before
handling the exceptional circumstance in your main
program loop --
this is akin to a 'deferred procedure call' in
Windows 2000+ device
driver programming). If it's not, then it probably
belongs to a
TLS/SSL connection, and can be safely ignored (since
you're supposed
to be checking the return statuses of all of your
OpenSSL calls
anyway, and since you're trying to shut down the SSL
socket, you might
as well just call SSL_free() immediately after the
SSL_shutdown
[taking into account the possibility of an
SSL_WANTS_WRITE return
status].
-Kyle H
__
OpenSSL Project
http://www.openssl.org
User Support Mailing List
openssl-users@openssl.org
Automated List Manager
[EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: SSL_shutdown and SIGPIPE
None of the solutions suggested by others in the list
will protect you against a SIGPIPE for the simple
reason that it is a fatal signal if not handled or
ignored and it can come at any time during the TCP
session...
Ignoring SIGPIPE is one of the steps in writing a
server daemon and it is standard practice.
Best,
Girish
--- Kyle Hamilton [EMAIL PROTECTED] wrote:
SIGPIPE is a remnant of BSD attempting to overlay
UNIX socket (named
pipe) semantics onto TCP/IP connections. If the
socket that you are
writing to is a socket (or pipe), AND the pipe is
closed, then you
receive a SIGPIPE.
In this case, the 'good reason' for it is that what
you think is
supposed to be listening isn't listening anymore, so
you may need to
update your internal state. However, since the
other effect of
writing to a socket that is remote-closed is the
descriptor itself
being closed, there's no reason to worry about it.
I help maintain a MUD software (that uses OpenSSL);
often players will
disconnect by closing their clients instead of using
the QUIT command,
and this leads to attempts to send information to
them. When the
software receives the TCP RST ('connection reset by
peer'), it also
receives a SIGPIPE. However, we have no need to
deal with it, since
we check the return status of the write operation;
if it fails, we
close the socket and clean up the memory allocated
to that connection.
On 2/12/06, Alberto Alonso [EMAIL PROTECTED]
wrote:
I personally don't know why pipes are even in use
in the openssl
internals (though I bet there is a good reason for
it :-)
It's there because the underlying operating system
forces them to be
there. It's certainly not at the behest of the
OpenSSL team.
Ignoring SIGPIPE (or most signals for that matter)
is not really
that good. They get generated for good reasons.
...explained above...
In my case, depending on what came down the wire,
I have to interact
with other utilities in the system, therefore
opening pipes. I need
to make sure I get the signals when a system tool
exits unexpectedly.
Alright, then just check to see what descriptor
actually caused the
SIGPIPE (instead of setting it to SIG_IGN, you
always have the ability
to write your own handler). If it's a descriptor
that connects to
another utility, handle that special case
(preferably by setting a
global variable and exiting the signal handler
quickly, before
handling the exceptional circumstance in your main
program loop --
this is akin to a 'deferred procedure call' in
Windows 2000+ device
driver programming). If it's not, then it probably
belongs to a
TLS/SSL connection, and can be safely ignored (since
you're supposed
to be checking the return statuses of all of your
OpenSSL calls
anyway, and since you're trying to shut down the SSL
socket, you might
as well just call SSL_free() immediately after the
SSL_shutdown
[taking into account the possibility of an
SSL_WANTS_WRITE return
status].
-Kyle H
__
OpenSSL Project
http://www.openssl.org
User Support Mailing List
openssl-users@openssl.org
Automated List Manager
[EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: SSL_shutdown and SIGPIPE
--- Kyle Hamilton [EMAIL PROTECTED] wrote:
SIGPIPE is a remnant of BSD attempting to overlay
UNIX socket (named
pipe) semantics onto TCP/IP connections. If the
socket that you are
writing to is a socket (or pipe), AND the pipe is
closed, then you
receive a SIGPIPE.
In this case, the 'good reason' for it is that what
you think is
supposed to be listening isn't listening anymore, so
you may need to
update your internal state. However, since the
other effect of
writing to a socket that is remote-closed is the
descriptor itself
being closed, there's no reason to worry about it.
I help maintain a MUD software (that uses OpenSSL);
often players will
disconnect by closing their clients instead of using
the QUIT command,
and this leads to attempts to send information to
them. When the
software receives the TCP RST ('connection reset by
peer'), it also
receives a SIGPIPE. However, we have no need to
deal with it, since
we check the return status of the write operation;
if it fails, we
close the socket and clean up the memory allocated
to that connection.
On 2/12/06, Alberto Alonso [EMAIL PROTECTED]
wrote:
I personally don't know why pipes are even in use
in the openssl
internals (though I bet there is a good reason for
it :-)
It's there because the underlying operating system
forces them to be
there. It's certainly not at the behest of the
OpenSSL team.
Ignoring SIGPIPE (or most signals for that matter)
is not really
that good. They get generated for good reasons.
...explained above...
In my case, depending on what came down the wire,
I have to interact
with other utilities in the system, therefore
opening pipes. I need
to make sure I get the signals when a system tool
exits unexpectedly.
Alright, then just check to see what descriptor
actually caused the
SIGPIPE (instead of setting it to SIG_IGN, you
always have the ability
to write your own handler). If it's a descriptor
that connects to
another utility, handle that special case
(preferably by setting a
global variable and exiting the signal handler
quickly, before
handling the exceptional circumstance in your main
program loop --
this is akin to a 'deferred procedure call' in
Windows 2000+ device
driver programming). If it's not, then it probably
belongs to a
TLS/SSL connection, and can be safely ignored (since
you're supposed
to be checking the return statuses of all of your
OpenSSL calls
anyway, and since you're trying to shut down the SSL
socket, you might
as well just call SSL_free() immediately after the
SSL_shutdown
[taking into account the possibility of an
SSL_WANTS_WRITE return
status].
-Kyle H
__
OpenSSL Project
http://www.openssl.org
User Support Mailing List
openssl-users@openssl.org
Automated List Manager
[EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
OBJ_create - a little problem.
Hi everybody! Here is the sample code: int nid; nid = OBJ_create(1.2.3.4, MyAlias, My Test Alias Extension); X509V3_EXT_add_alias(nid, NID_netscape_comment); add_ext(x, nid, Test Extension...); It works fine :) But I want to change the first parameter in OBJ_create() and I fail there. As I think, it have to be in some special format, but I can't found any info about it. Thanks a lot! __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL_shutdown and SIGPIPE
SIGPIPE is fatal if not handled or ignored and it can
come at any time during the TCP session. Which means
that none of the solutions suggested by others in the
list will work.
And it is wrong to rely on OpenSSL for solving a TCP
closure at the remote end which is essentially a TCP
issue.
write() or read() will return a 0 or -1 on a closed
socket, so you stand to lose nothing by ignoring
SIGPIPE.
regards,
Girish
--- Kyle Hamilton [EMAIL PROTECTED] wrote:
SIGPIPE is a remnant of BSD attempting to overlay
UNIX socket (named
pipe) semantics onto TCP/IP connections. If the
socket that you are
writing to is a socket (or pipe), AND the pipe is
closed, then you
receive a SIGPIPE.
In this case, the 'good reason' for it is that what
you think is
supposed to be listening isn't listening anymore, so
you may need to
update your internal state. However, since the
other effect of
writing to a socket that is remote-closed is the
descriptor itself
being closed, there's no reason to worry about it.
I help maintain a MUD software (that uses OpenSSL);
often players will
disconnect by closing their clients instead of using
the QUIT command,
and this leads to attempts to send information to
them. When the
software receives the TCP RST ('connection reset by
peer'), it also
receives a SIGPIPE. However, we have no need to
deal with it, since
we check the return status of the write operation;
if it fails, we
close the socket and clean up the memory allocated
to that connection.
On 2/12/06, Alberto Alonso [EMAIL PROTECTED]
wrote:
I personally don't know why pipes are even in use
in the openssl
internals (though I bet there is a good reason for
it :-)
It's there because the underlying operating system
forces them to be
there. It's certainly not at the behest of the
OpenSSL team.
Ignoring SIGPIPE (or most signals for that matter)
is not really
that good. They get generated for good reasons.
...explained above...
In my case, depending on what came down the wire,
I have to interact
with other utilities in the system, therefore
opening pipes. I need
to make sure I get the signals when a system tool
exits unexpectedly.
Alright, then just check to see what descriptor
actually caused the
SIGPIPE (instead of setting it to SIG_IGN, you
always have the ability
to write your own handler). If it's a descriptor
that connects to
another utility, handle that special case
(preferably by setting a
global variable and exiting the signal handler
quickly, before
handling the exceptional circumstance in your main
program loop --
this is akin to a 'deferred procedure call' in
Windows 2000+ device
driver programming). If it's not, then it probably
belongs to a
TLS/SSL connection, and can be safely ignored (since
you're supposed
to be checking the return statuses of all of your
OpenSSL calls
anyway, and since you're trying to shut down the SSL
socket, you might
as well just call SSL_free() immediately after the
SSL_shutdown
[taking into account the possibility of an
SSL_WANTS_WRITE return
status].
-Kyle H
__
OpenSSL Project
http://www.openssl.org
User Support Mailing List
openssl-users@openssl.org
Automated List Manager
[EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Is configuration without sockets possible?
Yes, thanks, I know about bio_pairs, and I think I know how to build an SSL channel over my custom communications device -- at least, in principle I do. I think I have been to terse in my original post. The problem is: I don't have anything like sys/socket.h, so the configuration should be done in such a way that e.g. bss_fd.c and bss_socket.c are not compiled. Rutger Usman Riaz wrote: Hi! One way is to use bio_pairs. There is an example of bio_pair usage in 'ssl_test.c' file in the OpenSSL package. Hope this helps, Regards, Usman. From: Rutger Hofman [EMAIL PROTECTED] Hi list, We are developing an embedded device where there are no sockets. We have other communication media, though, like radio signals, for which we need authentication/encryption, and OpenSSL is an obvious choice for that. Now, my question: Is configuration of OpenSSL without sockets possible? If so, how? If not, is there an easy way for me to factor them out by hand? Thanks, Rutger Hofman VU Amsterdam __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Is configuration without sockets possible?
On Mon, Feb 13, 2006, Rutger Hofman wrote: Yes, thanks, I know about bio_pairs, and I think I know how to build an SSL channel over my custom communications device -- at least, in principle I do. I think I have been to terse in my original post. The problem is: I don't have anything like sys/socket.h, so the configuration should be done in such a way that e.g. bss_fd.c and bss_socket.c are not compiled. You can try compiling with OPENSSL_NO_SOCK. That should in theory do what you want. However I don't know if it has been tested recently with that option so you may have to perform some minor or major tweaks to ensure all cases are covered. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Wildcard ssl certificate using subjectAltName
On Sat, Feb 11, 2006 at 01:34:28AM -0700, Kyle Hamilton wrote: It can be an IP, but I'm not sure about the encoding rules for it (SMTP requires an IP in the destination field to be in the form [192.168.1.1] (in square brackets) This is really the domain literal construct in the mailbox grammar of RFC822/821. It is not used alone. [EMAIL PROTECTED] subjectAltName=dNSName: domain.com subjectAltName=dNSName: *.domain.com subjectAltName=dNSName: *.*.domain.com The semantics of *.*.domain.com are poorly defined. It is not likely to work uniformly. The binding isn't done via IP address (as DNS can be spoofed), but rather by proof of possession of secret key. Specifically, IP addresses in certificates are only useful, if the client is configured to connect to a specific IP address and intends to verify said address. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Wildcard ssl certificate using subjectAltName
On Mon, Feb 13, 2006, Victor Duchovni wrote: On Sat, Feb 11, 2006 at 01:34:28AM -0700, Kyle Hamilton wrote: It can be an IP, but I'm not sure about the encoding rules for it (SMTP requires an IP in the destination field to be in the form [192.168.1.1] (in square brackets) This is really the domain literal construct in the mailbox grammar of RFC822/821. It is not used alone. [EMAIL PROTECTED] The semantics for dNSName, which this refers to are stricter. It has to be a hostname, cannot be an IP address (the iPAddress form is for that) and cannot contain wild cards. This is mentioned in RFC3280 et al. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL_shutdown and SIGPIPE
Girish Venkatachalam wrote: SIGPIPE is fatal if not handled or ignored and it can come at any time during the TCP session. Which means that none of the solutions suggested by others in the list will work. And it is wrong to rely on OpenSSL for solving a TCP closure at the remote end which is essentially a TCP issue. Not to say that OpenSSL is or is not partially culpable, but things like SIGPIPE/EPIPE are not _solely_ the responsibility of TCP. Connection close handshaking is the joint responsibility of TCP and its user. rick jones __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL_shutdown and SIGPIPE
Gayathri Sundar wrote: Probably you can call the following iRet = SSL_get_shutdown(pSSL); if(iRet = 0) SSL_shutdown(pSSL); This is because, SSL_shutdown writes data on the wire, i.e the closure alerts..and if a FIN was received meanwhile, you will catch a SIGPIPE..this piece of code, actually saves me from this.. Strictly speaking, it isn't that a FIN was received. Receipt of the FIN in and of itself does not mean that the remote TCP endpoint is gone, nor that it is unwilling to accept more data. All a FIN means in and of itself is that the remote TCP and application will be sending no more data our way on the connection. For example, when the remote simply calls shutdown(SHUT_WR). Now, we also receive a FIN when the remote calls close(). In this sitation, while it was unable to communicate that via TCP, the remote is not willing to recieve any more data. The close() has implicitly stated such to the remote TCP, so when the remote TCP recieves our data, it becomes upset/worried/concernec/confused tosses its hands in the air and sends us a RST segment. Receipt of that RST segment puts our end of the TCP connection into an aborted state, and an attempt to write to the socket generates the SIGPIPE. Generally, this will not be seen by us until our _second_ access of the socket - first the write to trigger the RST from the remote, and then some other socket call - typically another write IIRC, but I think it could be a recv. SIGPIPE/EPIPE is our local TCP's way of telling us that we screwed-up in the application-level handshaking between the ends. A variation of the close() scenario is if the remote application is (bogusly IMO) using an abortive close a la SO_LINGER. In that case they emit a RST and go away. Either we receive that RST and go SIGPIPE/EPIPE on the next socket call, or we don't see that RST (it is lost) and we follow a path much like the FIN. The only way to be more or less sure we won't get an EPIPE/SIGPIPE is to preface all our socket calls with something like select() or poll(), and even then there is still a small window of a race condition, and of course the slight matter of the select/poll overhead... rick jones __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL_shutdown and SIGPIPE
Thanks for the detailed explanation, it clearly helped my
understanding of the whole thing.
I obviously already have a SIGPIPE handler, but the difficulty
comes from trying to figure out which call generated the signal.
As the code is meant to work on Linux and windows, and my understanding
is that the windows pthreads implementation doesn't do per thread
signals it becomes even more difficult to pinpoint the culprit.
Proper checking of all the return codes helps (and that's what I've
been doing anyway). I was trying to use a SIGPIPE as an indication of a
problem with the system tools interaction, but it is clear now that
it was a simplistic approach.
Thanks,
Alberto
On Mon, 2006-02-13 at 06:42 -0700, Kyle Hamilton wrote:
SIGPIPE is a remnant of BSD attempting to overlay UNIX socket (named
pipe) semantics onto TCP/IP connections. If the socket that you are
writing to is a socket (or pipe), AND the pipe is closed, then you
receive a SIGPIPE.
In this case, the 'good reason' for it is that what you think is
supposed to be listening isn't listening anymore, so you may need to
update your internal state. However, since the other effect of
writing to a socket that is remote-closed is the descriptor itself
being closed, there's no reason to worry about it.
I help maintain a MUD software (that uses OpenSSL); often players will
disconnect by closing their clients instead of using the QUIT command,
and this leads to attempts to send information to them. When the
software receives the TCP RST ('connection reset by peer'), it also
receives a SIGPIPE. However, we have no need to deal with it, since
we check the return status of the write operation; if it fails, we
close the socket and clean up the memory allocated to that connection.
On 2/12/06, Alberto Alonso [EMAIL PROTECTED] wrote:
I personally don't know why pipes are even in use in the openssl
internals (though I bet there is a good reason for it :-)
It's there because the underlying operating system forces them to be
there. It's certainly not at the behest of the OpenSSL team.
Ignoring SIGPIPE (or most signals for that matter) is not really
that good. They get generated for good reasons.
...explained above...
In my case, depending on what came down the wire, I have to interact
with other utilities in the system, therefore opening pipes. I need
to make sure I get the signals when a system tool exits unexpectedly.
Alright, then just check to see what descriptor actually caused the
SIGPIPE (instead of setting it to SIG_IGN, you always have the ability
to write your own handler). If it's a descriptor that connects to
another utility, handle that special case (preferably by setting a
global variable and exiting the signal handler quickly, before
handling the exceptional circumstance in your main program loop --
this is akin to a 'deferred procedure call' in Windows 2000+ device
driver programming). If it's not, then it probably belongs to a
TLS/SSL connection, and can be safely ignored (since you're supposed
to be checking the return statuses of all of your OpenSSL calls
anyway, and since you're trying to shut down the SSL socket, you might
as well just call SSL_free() immediately after the SSL_shutdown
[taking into account the possibility of an SSL_WANTS_WRITE return
status].
-Kyle H
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
--
Alberto AlonsoGlobal Gate Systems LLC.
(512) 351-7233http://www.ggsys.net
Hardware, consulting, sysadmin, monitoring and remote backups
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
[Crypt::SSLeay] mod_ssl overrides settings by mod_perl applications?
I'm having a problem getting Crypt::SSLeay to authenticate server certificates when running under mod_perl on a web server that has mod_ssl enabled. I'm not sure if this is a bug with Crypt::SSLeay, mod_ssl, mod_perl, Net::SSLeay, or the underlying OpenSSL libraries, but I'm hoping someone here will at least be able to narrow down where the problem lies. Additionally, I'm running under a fairly old Linux distribution (Red Hat AS 3.0) with Perl 5.8.0, Apache 2.0.40,mod_perl 1.99_07, and libssl 0.9.6, but given that I haven't seen this problem reported anywhere else, let alone reported as having been fixed, I'm fairly confident that it still applies to more recent software versions. Here's an overview of what I'm trying to do: I've written a component that runs on a Perl-based web portal system residing under mod_perl on an Apache web server configured with mod_ssl. User authentication is handled by the Perl-based portal framework, and my component connects to a servlet on a Tomcat server residing on a separate machine. Due to the sensitive nature of the data being handled, all connections (from the user to the web server and from the web server to Tomcat) are being done via HTTPS. For security reasons, I need to validate the Tomcat server's certificate. I'm using LWP::UserAgent in conjunction with Crypt::SSLeay, and my Perl component is setting the appropriate environment variable (HTTPS_CA_FILE and/or HTTPS_CA_DIR, I've tried both) as per the Crypt::SSLeay documentation. As a test scenario, I configured Tomcat with a self-signed certificate, and my component is using a bogus CA bundle. The expected behavior is that the connection to Tomcat should fail due to the mismatched certificates. However, what actually happens is that all requests sent to Tomcat succeed without even so much as a warning about the invalid certificate. In the process of trying to narrow down the cause of the problem, I tried a number of things. I tried running the snippet of code handling the HTTPS request to Tomcat as a standalone script with the exact same (mismatched) certificates in place. This resulted in the expected behavior (failuredue to invalid server certificate). I tried disabling mod_ssl and connecting to the web server via HTTP instead of HTTPS (while still using HTTPS for the connection to Tomcat). This also resulted in the expected behavior. I tried running the snippet of code as a standalone script that gets invoked (in backticks) by my mod_perl component. This resulted in the expected behavior. It's only when mod_ssl is enabled that my component behaves incorrectly and fails to properly validate the server's certificate against the CA bundle. My best guess at what's happening is that mod_ssl is preloading libssl and configuring it according to its own requirements (andmod_ssl doesn't care about the certificates of other servers), and when my code runs (later)under mod_perl, the variables I'm sending it are being completely ignored. Can this be fixed, or can anyone think of any viable workarounds for this (that don't involve running my code as a standalone script)? Thanks.
EFS Certificates
List, Has anyone used OpenSSL to create EFS certificates? Any recommendations on using OpenSSL to create EFS certificates will be greatly appreciated. Regards, David
Re: OBJ_create - a little problem.
On Mon, Feb 13, 2006, [EMAIL PROTECTED] wrote: Hi everybody! Here is the sample code: int nid; nid = OBJ_create(1.2.3.4, MyAlias, My Test Alias Extension); X509V3_EXT_add_alias(nid, NID_netscape_comment); add_ext(x, nid, Test Extension...); It works fine :) But I want to change the first parameter in OBJ_create() and I fail there. As I think, it have to be in some special format, but I can't found any info about it. It is the stndard dotted form of an OBJECT IDENTIFIER. Roughly speaking a sequence of two or more non-negative integers separated by dots. The first number can be 0, 1 or 2. The second 0 to 39 unless the first number is 2 in which case it can take any value. Subsequent numbers can take any value, though it is usual to keep them relatively small (say 32 bits maximum). The first few digits are often reserved for certain origanizations and they can define the meaning of objects within their arc. You shouldn't therefore just make up a random set of digits especially if it to appear in anything public. You can apply for your own arc. One place where you can do this is: http://www.iana.org/cgi-bin/enterprise.pl The OpenSSL group for example is: 1.3.6.1.4.1.16604 Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [Crypt::SSLeay] mod_ssl overrides settings by mod_perl applications?
Richard Eggert wrote: ... My best guess at what's happening is that mod_ssl is preloading libssl and configuring it according to its own requirements (and mod_ssl doesn't care about the certificates of other servers), and when my code runs (later) under mod_perl, the variables I'm sending it are being completely ignored. Apache/mod_ssl server configuration should not interfere with your libwww-perl/OpenSSL client configuration in any way. try to do some printf debugging and print the relevant environment variable values to a log file. do the variables have the correct values when the script is being run? br. aspa __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [Crypt::SSLeay] mod_ssl overrides settings by mod_perl applications?
Yep. Environment variables are being set. I've even tried including a SetEnv in the Apache config instead of setting the variables inside my code. I've written them to the log, and they're definitely being set. They're just being ignored. As I said before, the problem goes away if I just disable mod_ssl and connect to the server using regular HTTP (while continuing to use HTTPS to connect to Tomcat within my code). mod_ssl on = HTTPS_CA_FILE ignored (or the code that's executed by whatever reads the variable fails for some reason). mod_ssl off = HTTPS_CA_FILE gets used to validate Tomcat's certificate. I can only assume that some global variable is being set when mod_ssl is configured that causes the change to HTTPS_CA_FILE (or HTTPS_CA_DIR) to be ignored when they're used by code running within mod_perl. Two of us worked on it for hours and that's the only conclusion we could draw, though neither of would have thought that was the case before we saw it for ourselves. Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com From: [EMAIL PROTECTED] on behalf of Marko Asplund Sent: Mon 2/13/2006 2:13 PM To: openssl-users@openssl.org Subject: Re: [Crypt::SSLeay] mod_ssl overrides settings by mod_perl applications? Richard Eggert wrote: ... My best guess at what's happening is that mod_ssl is preloading libssl and configuring it according to its own requirements (and mod_ssl doesn't care about the certificates of other servers), and when my code runs (later) under mod_perl, the variables I'm sending it are being completely ignored. Apache/mod_ssl server configuration should not interfere with your libwww-perl/OpenSSL client configuration in any way. try to do some printf debugging and print the relevant environment variable values to a log file. do the variables have the correct values when the script is being run? br. aspa __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] winmail.dat
SSL v2/3 and TLS.. How to be flexible?
Hey Folks, I've hit a bit of a wall here. I want to build a simple client and server that can handle SSL and TLS connections. It's not turning out as simple as it looks and googling hasn't yielded a solution either. Put simply. If I create a client-server where one end uses TLSv1_method() and the other uses SSLv23_method(), they refuse to negotiate. If both ends are set to SSLv23_method() then I see (from SSL_get_current_cipher) that an SSLv3 connection is negotiated (wish it was TLS, then i'd be happy). Is there some (hopefully easy) method to create a server that can handle either SSL or TLS incoming connections? Or, if both ends support it, negotiate to TLS? TIA, -lee __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL v2/3 and TLS.. How to be flexible?
TLSv1_server_methods() do not speak the crufty old SSLv2 garbage, you can't connect to it using a multi-protocol handshake. For maxiumum portability use SSLv23_server_methods() On the client side it doesn't matter, if you want a TLSv1 connection only, then by all means use TLSv1_client_methods(). Lee Dilkie wrote: Hey Folks, I've hit a bit of a wall here. I want to build a simple client and server that can handle SSL and TLS connections. It's not turning out as simple as it looks and googling hasn't yielded a solution either. Put simply. If I create a client-server where one end uses TLSv1_method() and the other uses SSLv23_method(), they refuse to negotiate. If both ends are set to SSLv23_method() then I see (from SSL_get_current_cipher) that an SSLv3 connection is negotiated (wish it was TLS, then i'd be happy). Is there some (hopefully easy) method to create a server that can handle either SSL or TLS incoming connections? Or, if both ends support it, negotiate to TLS? TIA, -lee __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
AES cipher
I'm trying to allow my program to be configurable for either AES 128
bit, or AES 256 bit. The problem is that when I select only the
AES128-SHA cipher, the other AES ciphers (including 256 bit) get added
automaticlly.
Is this a limitation of selecting AES, or am I doing something wrong?
Here is my code:
1. Set cyphers:
CString Shif = AES128-SHA;
Shif+=!IDEA:!ADH:;
SSL_CTX_set_cipher_list(m_ctx, Shif.GetBuffer());
SSL_CTX_set_options(SSL_OP_NO_SSLv2);
2. Display chypers:
SSL* lSSL = SSL_new(lCTX);
int ccnt=0;
const char *res=(char*)1;
for (int i=0;res!=NULL;i++)
{
res = SSL_get_cipher_list(lSSL, i);
if (res)
{
m_List.AddString((char*)res);
ccnt++;
}
}
-Chris Clark
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
RE: [Crypt::SSLeay] mod_ssl overrides settings by mod_perl applications?
I've been digging through the code of the libraries for LWP, etc., and
discovered that Net::HTTPS contains the following code:
if ($IO::Socket::SSL::VERSION){
$SSL_SOCKET_CLASS = IO::Socket::SSL; # it was already loaded
}
else {
eval { require Net::SSL; }; # from Crypt-SSLeay
if ($@) {
my $olderrsv = $@;
eval {
require IO::Socket::SSL;
};
if ($@) {
$old_errsv =~ s/\s\([EMAIL PROTECTED] contains:.*\)/)/g;
die $old_errsv . $@;
}
$SSL_SOCKET_CLASS = IO::Socket::SSL;
}
else {
$SSL_SOCKET_CLASS = Net::SSL;
}
}
It seems that it first tries to load the SSL module from Crypt::SSLeay first,
and if that fails, it then tries to load IO::Socket::SSL, which, as far as I
can tell, doesn't use HTTPS_CA_FILE (but may provide another mechanism for
accomplishing the same thing). Could it be that perhaps loading mod_ssl is
causing the load of Net::SSL to fail (symbol conflict?), resulting in it
falling back to IO::Socket::SSL (which ignores HTTPS_CA_FILE)?
Does IO::Socket::SSL provide a means for passing parameters via LWP::UserAgent
(maybe through UserAgent's constructor or one of its other methods?)? It
definitely seems to support verification of peer certificates in its interface,
but it's unclear from the available documentation how one does that in
conjunction with LWP::UserAgent, if that's even possible. If there is a way to
do this, then an easy workaround seems to be to simply accomodate both
configuration methods in my code.
Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com
From: [EMAIL PROTECTED] on behalf of Marko Asplund
Sent: Mon 2/13/2006 2:13 PM
To: openssl-users@openssl.org
Subject: Re: [Crypt::SSLeay] mod_ssl overrides settings by mod_perl
applications?
Richard Eggert wrote:
...
My best guess at what's happening is that mod_ssl is preloading libssl
and configuring it according to its own requirements (and mod_ssl
doesn't care about the certificates of other servers), and when my code
runs (later) under mod_perl, the variables I'm sending it are being
completely ignored.
Apache/mod_ssl server configuration should not interfere with your
libwww-perl/OpenSSL client configuration in any way.
try to do some printf debugging and print the relevant environment
variable values to a log file. do the variables have the correct values
when the script is being run?
br. aspa
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
winmail.dat
Re: AES cipher
On Mon, Feb 13, 2006 at 12:34:42PM -0800, Chris Clark wrote:
I'm trying to allow my program to be configurable for either AES 128
bit, or AES 256 bit. The problem is that when I select only the
AES128-SHA cipher, the other AES ciphers (including 256 bit) get added
automaticlly.
Is this a limitation of selecting AES, or am I doing something wrong?
Here is my code:
1. Set cyphers:
CString Shif = AES128-SHA;
Shif+=!IDEA:!ADH:;
You probably have to add some : here. With the explicit selection of
AES128-SHA you do not have to remove the other ciphers anyway.
SSL_CTX_set_cipher_list(m_ctx, Shif.GetBuffer());
SSL_CTX_set_options(SSL_OP_NO_SSLv2);
2. Display chypers:
SSL* lSSL = SSL_new(lCTX);
int ccnt=0;
const char *res=(char*)1;
for (int i=0;res!=NULL;i++)
{
res = SSL_get_cipher_list(lSSL, i);
if (res)
{
m_List.AddString((char*)res);
ccnt++;
}
}
The openssl command line tool seems to handle problem well...
lutzpc 30: openssl ciphers -v AES128-SHA
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
RE: Hard-coded keys and cert in the image
Thanks Chong Peng! It worked.
The only thing I had to change was to pass in parameters in the following
function calls.
Instead of:
PEM_read_bio_x509(bio, NULL, NULL, NULL);
PEM_read_bio_PrivateKey(bio, NULL, NULL, NULL)
I did:
PEM_read_bio_x509(bio, NULL, ctx-default_passwd_callback,
ctx-default_passwd_callback_userdata);
PEM_read_bio_PrivateKey(bio, NULL, ctx-default_passwd_callback,
ctx-default_passwd_callback_userdata);
Thanks,
-Grace
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chong Peng
Sent: Thursday, February 09, 2006 5:36 PM
To: openssl-users@openssl.org
Subject: RE: Hard-coded keys and cert in the image
forget one thing, after you have the private key (of type EVP_PKEY) and
certificate (of type X509, you use:
SSL_CTX_use_certificate(ctx,cert) and SSL_CTX_use_PrivateKey(ctx, pkey)
to read them into your ssl context.
-Original Message-
From: Chong Peng
Sent: Thursday, February 09, 2006 5:25 PM
To: openssl-users@openssl.org
Subject: RE: Hard-coded keys and cert in the image
grace:
i believe what your are trying to do is what i did a few days ago. here is how
you do it:
1. obtain the private key and certificate in pem format, e.g., by using the
following openssl command:
$ openssl genrsa -out key.pem 1024
$ openssl req -new -key key.pem -out request.pem
$ openssl x509 -req -days 30 -in request.pem -signkey key.pem -out
certificate.pem $ openssl x509 -inform der -in certificate.crt -out
certificate.pem
this will give you a self signed private key and certificate (in pem format).
2. open the pem files (e.g., key.pem and certificate.pem) in a text editor,
copy and paste the the key and certificate to a c array.
3. your c code is going to look like the following:
#include buffer.h
#include pem.h
#include evp.h
#include bio.h
#include x509.h
EVP_PKEY*pkey = NULL;
X509*cert = NULL;
const char skey[] =
-BEGIN RSA PRIVATE KEY-
MIICXAIBAAKBgQC0SF/4JTo3XzffsPeNPbglZ6sz/f/mlUO/CUtB8hk0DTz3V/9r
iWagrVHjqaF/xikWFsxbzKecRyDDNyhgMWV8eeAVGpJSvmyJZH43MWO1zCiBXsi2
MSHqQAJOfT803qTc3tPCb5k4UK5ytvwpQ8ZIyokrnQJS0FYKsonf3ASjKwIDAQAB
AoGAMR3Sv6lsze8sKs5s81cQV2iCFT0rPegGuAJRNZs+0JaWuJCJ7wNVKYtu1wa9
EDGtue3mKVB9ja83NthNML/kdOszLc1G6NVnWYSzgBPPsyPAJkSZw8TQKODmw+LF
sqGFjC73s49/lWO12Tv8qA0Zf4sXRY9dMiqX5kA5m8OWXfECQQDYkv2B1xfNK41v
PPeggVapasX53ZIiOdjc5UuaOWU7GDLhlyyFUCkDdx4eviBAEclWfNSueJNcK1Me
pulScGFTAkEA1RoXxsYgFVbZsK1i9hjxEqoWzP7dQBJTWqi/77BaPQvqX12ctVk0
pa0sR4XEKxGOBr11XJVlloTjpmm1hwLDyQJBAM25o1IpLhTZIDrgoSE4e0fngzQ9
A0m7xYLf1RclGkIuVHbykXn5kVwXVOdDF4OE4cpkPeuV4fUVuplNWCnVUr0CQBWR
a4ChwtOGE8hO9ComQhf6gQ5EaU43zJnrZGm09p0hHJqEVf0Ax1RRX57pif4166MA
/+Tb9gky7/uCzW2ZuQkCQFUoAhZnV9sQoifQpkCE10J3fZNyNLEvHKU3b4/rwvn7
5W618+Fr0DiwBkH07YSWRCVvi8rsYrK2/25DXSbXbD8=
-END RSA PRIVATE KEY-;
const char scert[] =
-BEGIN CERTIFICATE-
MIICeTCCAeICCQDVIB2PKnpDmjANBgkqhkiG9w0BAQUFADCBgDELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAkNBMRAwDgYDVQQHEwdTQU5KT1NFMQ8wDQYDVQQKEwZNQVhY
QU4xDDAKBgNVBAsTA0VORzEOMAwGA1UEAxMFY2hvbmcxIzAhBgkqhkiG9w0BCQEW
FGNob25ncGVuZ0BtYXh4YW4uY29tMB4XDTA1MTIyMTA0MDcxNloXDTA2MDEyMDA0
MDcxNlowgYAxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEQMA4GA1UEBxMHU0FO
Sk9TRTEPMA0GA1UEChMGTUFYWEFOMQwwCgYDVQQLEwNFTkcxDjAMBgNVBAMTBWNo
b25nMSMwIQYJKoZIhvcNAQkBFhRjaG9uZ3BlbmdAbWF4eGFuLmNvbTCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEAtEhf+CU6N18337D3jT24JWerM/3/5pVDvwlL
QfIZNA0891f/a4lmoK1R46mhf8YpFhbMW8ynnEcgwzcoYDFlfHngFRqSUr5siWR+
NzFjtcwogV7ItjEh6kACTn0/NN6k3N7Twm+ZOFCucrb8KUPGSMqJK50CUtBWCrKJ
39wEoysCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBX0jTsC73wXYHDhenL2piboCMQ
qF96W/YLShYJla3ipc8JG0GHStTjUY4w7KGjDJippRUhddv0CUAilD7EPYusr1oY
sk+Tt7QKCSLnued6NZwGnjIV78BmMi5gp5UEotgmPMk6Q6WKl0rVMbiJWqgy9f7b
Hk3SUgTCdn/T+ajIFQ==
-END CERTIFICATE-;
int serverKey(void)
{
BIO *bio;
if( (bio=BIO_new_mem_buf((void *)skey, sizeof(skey))) == NULL)
{
return(-1);
}
if( (pkey=PEM_read_bio_PrivateKey(bio, NULL, NULL, NULL)) == NULL)
{
BIO_free(bio);
return(-1);
}
BIO_free(bio);
return(0);
}
int serverCert(void)
{
BIO *bio;
if( (bio=BIO_new_mem_buf((void *)scert, sizeof(scert))) == NULL)
{
return(-1);
}
if( (cert=PEM_read_bio_X509(bio, NULL, NULL, NULL)) == NULL)
{
BIO_free(bio);
return(-1);
}
BIO_free(bio);
return(0);
}
this piece of code worked in the embedded system i am working on, hope this
helps.
chong peng
-Original Message-
From: Xie Grace Jingru-LJX001 [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 09, 2006 9:47 AM
To: openssl-users@openssl.org
Subject: Hard-coded keys and cert in the image
Hello,
If the privkey and cacert have to be hard-coded in the image (by using
#define), how can I tell SSL to look into these constants for the key and cert
instead of the default
Re: Hard-coded keys and cert in the image
Sure, tomorrow though.
My kids don't give me much time to think on computer stuff here at home. ;)
In message [EMAIL PROTECTED], Xie Grace Jingru-LJX001 writes:
Thanks Chong Peng! It worked.
The only thing I had to change was to pass in parameters in the following
function calls.
Instead of:
PEM_read_bio_x509(bio, NULL, NULL, NULL);
PEM_read_bio_PrivateKey(bio, NULL, NULL, NULL)
I did:
PEM_read_bio_x509(bio, NULL, ctx-default_passwd_callback,
ctx-default_passwd_callback_userdata);
PEM_read_bio_PrivateKey(bio, NULL, ctx-default_passwd_callback,
ctx-default_passwd_callback_userdata);
Thanks,
-Grace
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chong Peng
Sent: Thursday, February 09, 2006 5:36 PM
To: openssl-users@openssl.org
Subject: RE: Hard-coded keys and cert in the image
forget one thing, after you have the private key (of type EVP_PKEY) and
certificate (of type X509, you use:
SSL_CTX_use_certificate(ctx,cert) and SSL_CTX_use_PrivateKey(ctx, pkey)
to read them into your ssl context.
-Original Message-
From: Chong Peng
Sent: Thursday, February 09, 2006 5:25 PM
To: openssl-users@openssl.org
Subject: RE: Hard-coded keys and cert in the image
grace:
i believe what your are trying to do is what i did a few days ago. here is how
you do it:
1. obtain the private key and certificate in pem format, e.g., by using the
following openssl command:
$ openssl genrsa -out key.pem 1024
$ openssl req -new -key key.pem -out request.pem
$ openssl x509 -req -days 30 -in request.pem -signkey key.pem -out
certificate.pem $ openssl x509 -inform der -in certificate.crt -out
certificate.
pem
this will give you a self signed private key and certificate (in pem format).
2. open the pem files (e.g., key.pem and certificate.pem) in a text editor,
copy and paste the the key and certificate to a c array.
3. your c code is going to look like the following:
#include buffer.h
#include pem.h
#include evp.h
#include bio.h
#include x509.h
EVP_PKEY *pkey = NULL;
X509 *cert = NULL;
const char skey[] =
-BEGIN RSA PRIVATE KEY-
MIICXAIBAAKBgQC0SF/4JTo3XzffsPeNPbglZ6sz/f/mlUO/CUtB8hk0DTz3V/9r
iWagrVHjqaF/xikWFsxbzKecRyDDNyhgMWV8eeAVGpJSvmyJZH43MWO1zCiBXsi2
MSHqQAJOfT803qTc3tPCb5k4UK5ytvwpQ8ZIyokrnQJS0FYKsonf3ASjKwIDAQAB
AoGAMR3Sv6lsze8sKs5s81cQV2iCFT0rPegGuAJRNZs+0JaWuJCJ7wNVKYtu1wa9
EDGtue3mKVB9ja83NthNML/kdOszLc1G6NVnWYSzgBPPsyPAJkSZw8TQKODmw+LF
sqGFjC73s49/lWO12Tv8qA0Zf4sXRY9dMiqX5kA5m8OWXfECQQDYkv2B1xfNK41v
PPeggVapasX53ZIiOdjc5UuaOWU7GDLhlyyFUCkDdx4eviBAEclWfNSueJNcK1Me
pulScGFTAkEA1RoXxsYgFVbZsK1i9hjxEqoWzP7dQBJTWqi/77BaPQvqX12ctVk0
pa0sR4XEKxGOBr11XJVlloTjpmm1hwLDyQJBAM25o1IpLhTZIDrgoSE4e0fngzQ9
A0m7xYLf1RclGkIuVHbykXn5kVwXVOdDF4OE4cpkPeuV4fUVuplNWCnVUr0CQBWR
a4ChwtOGE8hO9ComQhf6gQ5EaU43zJnrZGm09p0hHJqEVf0Ax1RRX57pif4166MA
/+Tb9gky7/uCzW2ZuQkCQFUoAhZnV9sQoifQpkCE10J3fZNyNLEvHKU3b4/rwvn7
5W618+Fr0DiwBkH07YSWRCVvi8rsYrK2/25DXSbXbD8=
-END RSA PRIVATE KEY-;
const char scert[] =
-BEGIN CERTIFICATE-
MIICeTCCAeICCQDVIB2PKnpDmjANBgkqhkiG9w0BAQUFADCBgDELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAkNBMRAwDgYDVQQHEwdTQU5KT1NFMQ8wDQYDVQQKEwZNQVhY
QU4xDDAKBgNVBAsTA0VORzEOMAwGA1UEAxMFY2hvbmcxIzAhBgkqhkiG9w0BCQEW
FGNob25ncGVuZ0BtYXh4YW4uY29tMB4XDTA1MTIyMTA0MDcxNloXDTA2MDEyMDA0
MDcxNlowgYAxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEQMA4GA1UEBxMHU0FO
Sk9TRTEPMA0GA1UEChMGTUFYWEFOMQwwCgYDVQQLEwNFTkcxDjAMBgNVBAMTBWNo
b25nMSMwIQYJKoZIhvcNAQkBFhRjaG9uZ3BlbmdAbWF4eGFuLmNvbTCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEAtEhf+CU6N18337D3jT24JWerM/3/5pVDvwlL
QfIZNA0891f/a4lmoK1R46mhf8YpFhbMW8ynnEcgwzcoYDFlfHngFRqSUr5siWR+
NzFjtcwogV7ItjEh6kACTn0/NN6k3N7Twm+ZOFCucrb8KUPGSMqJK50CUtBWCrKJ
39wEoysCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBX0jTsC73wXYHDhenL2piboCMQ
qF96W/YLShYJla3ipc8JG0GHStTjUY4w7KGjDJippRUhddv0CUAilD7EPYusr1oY
sk+Tt7QKCSLnued6NZwGnjIV78BmMi5gp5UEotgmPMk6Q6WKl0rVMbiJWqgy9f7b
Hk3SUgTCdn/T+ajIFQ==
-END CERTIFICATE-;
int serverKey(void)
{
BIO *bio;
if( (bio=BIO_new_mem_buf((void *)skey, sizeof(skey))) == NULL)
{
return(-1);
}
if( (pkey=PEM_read_bio_PrivateKey(bio, NULL, NULL, NULL)) == NULL)
{
BIO_free(bio);
return(-1);
}
BIO_free(bio);
return(0);
}
int serverCert(void)
{
BIO *bio;
if( (bio=BIO_new_mem_buf((void *)scert, sizeof(scert))) == NULL)
{
return(-1);
}
if( (cert=PEM_read_bio_X509(bio, NULL, NULL, NULL)) == NULL)
{
BIO_free(bio);
return(-1);
}
BIO_free(bio);
return(0);
}
this piece of code worked in the embedded system i am working on, hope this
helps.
chong peng
-Original Message-
From: Xie Grace Jingru-LJX001 [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 09, 2006 9:47 AM
To: openssl-users@openssl.org
Subject: Hard-coded keys and cert in the image
Hello,
If the privkey and cacert have to be
Re: Wildcard ssl certificate using subjectAltName
Has anyone successfully create a double wildcard certificate (*.*.domain.com) ? Does it work with MSIE 6 XP service pack 2 ? Attached is my openssl.cnf, my test CSR, and my test certificate. Can you please see if anything wrong? Does anyone has a working certificate with subjectAltName that I can take a look ? Thank you Khai From: Dr. Stephen Henson [EMAIL PROTECTED] Reply-To: openssl-users@openssl.org To: openssl-users@openssl.org Subject: Re: Wildcard ssl certificate using subjectAltName Date: Mon, 13 Feb 2006 18:47:19 +0100 On Mon, Feb 13, 2006, Victor Duchovni wrote: On Sat, Feb 11, 2006 at 01:34:28AM -0700, Kyle Hamilton wrote: It can be an IP, but I'm not sure about the encoding rules for it (SMTP requires an IP in the destination field to be in the form [192.168.1.1] (in square brackets) This is really the domain literal construct in the mailbox grammar of RFC822/821. It is not used alone. [EMAIL PROTECTED] The semantics for dNSName, which this refers to are stricter. It has to be a hostname, cannot be an IP address (the iPAddress form is for that) and cannot contain wild cards. This is mentioned in RFC3280 et al. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Hard-coded keys and cert in the image
Oh, sorry, wrong list...
In message [EMAIL PROTECTED], Sly Upah writes:
Sure, tomorrow though.
My kids don't give me much time to think on computer stuff here at home. ;)
In message [EMAIL PROTECTED], Xie Grace Jingru-LJX001 writes:
Thanks Chong Peng! It worked.
The only thing I had to change was to pass in parameters in the following
function calls.
Instead of:
PEM_read_bio_x509(bio, NULL, NULL, NULL);
PEM_read_bio_PrivateKey(bio, NULL, NULL, NULL)
I did:
PEM_read_bio_x509(bio, NULL, ctx-default_passwd_callback,
ctx-default_passwd_callback_userdata);
PEM_read_bio_PrivateKey(bio, NULL, ctx-default_passwd_callback,
ctx-default_passwd_callback_userdata);
Thanks,
-Grace
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chong Peng
Sent: Thursday, February 09, 2006 5:36 PM
To: openssl-users@openssl.org
Subject: RE: Hard-coded keys and cert in the image
forget one thing, after you have the private key (of type EVP_PKEY) and
certificate (of type X509, you use:
SSL_CTX_use_certificate(ctx,cert) and SSL_CTX_use_PrivateKey(ctx, pkey)
to read them into your ssl context.
-Original Message-
From: Chong Peng
Sent: Thursday, February 09, 2006 5:25 PM
To: openssl-users@openssl.org
Subject: RE: Hard-coded keys and cert in the image
grace:
i believe what your are trying to do is what i did a few days ago. here is
how you do it:
1. obtain the private key and certificate in pem format, e.g., by using the
following openssl command:
$ openssl genrsa -out key.pem 1024
$ openssl req -new -key key.pem -out request.pem
$ openssl x509 -req -days 30 -in request.pem -signkey key.pem -out
certificate.pem $ openssl x509 -inform der -in certificate.crt -out
certificate.
pem
this will give you a self signed private key and certificate (in pem format).
2. open the pem files (e.g., key.pem and certificate.pem) in a text editor,
copy and paste the the key and certificate to a c array.
3. your c code is going to look like the following:
#include buffer.h
#include pem.h
#include evp.h
#include bio.h
#include x509.h
EVP_PKEY *pkey = NULL;
X509 *cert = NULL;
const char skey[] =
-BEGIN RSA PRIVATE KEY-
MIICXAIBAAKBgQC0SF/4JTo3XzffsPeNPbglZ6sz/f/mlUO/CUtB8hk0DTz3V/9r
iWagrVHjqaF/xikWFsxbzKecRyDDNyhgMWV8eeAVGpJSvmyJZH43MWO1zCiBXsi2
MSHqQAJOfT803qTc3tPCb5k4UK5ytvwpQ8ZIyokrnQJS0FYKsonf3ASjKwIDAQAB
AoGAMR3Sv6lsze8sKs5s81cQV2iCFT0rPegGuAJRNZs+0JaWuJCJ7wNVKYtu1wa9
EDGtue3mKVB9ja83NthNML/kdOszLc1G6NVnWYSzgBPPsyPAJkSZw8TQKODmw+LF
sqGFjC73s49/lWO12Tv8qA0Zf4sXRY9dMiqX5kA5m8OWXfECQQDYkv2B1xfNK41v
PPeggVapasX53ZIiOdjc5UuaOWU7GDLhlyyFUCkDdx4eviBAEclWfNSueJNcK1Me
pulScGFTAkEA1RoXxsYgFVbZsK1i9hjxEqoWzP7dQBJTWqi/77BaPQvqX12ctVk0
pa0sR4XEKxGOBr11XJVlloTjpmm1hwLDyQJBAM25o1IpLhTZIDrgoSE4e0fngzQ9
A0m7xYLf1RclGkIuVHbykXn5kVwXVOdDF4OE4cpkPeuV4fUVuplNWCnVUr0CQBWR
a4ChwtOGE8hO9ComQhf6gQ5EaU43zJnrZGm09p0hHJqEVf0Ax1RRX57pif4166MA
/+Tb9gky7/uCzW2ZuQkCQFUoAhZnV9sQoifQpkCE10J3fZNyNLEvHKU3b4/rwvn7
5W618+Fr0DiwBkH07YSWRCVvi8rsYrK2/25DXSbXbD8=
-END RSA PRIVATE KEY-;
const char scert[] =
-BEGIN CERTIFICATE-
MIICeTCCAeICCQDVIB2PKnpDmjANBgkqhkiG9w0BAQUFADCBgDELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAkNBMRAwDgYDVQQHEwdTQU5KT1NFMQ8wDQYDVQQKEwZNQVhY
QU4xDDAKBgNVBAsTA0VORzEOMAwGA1UEAxMFY2hvbmcxIzAhBgkqhkiG9w0BCQEW
FGNob25ncGVuZ0BtYXh4YW4uY29tMB4XDTA1MTIyMTA0MDcxNloXDTA2MDEyMDA0
MDcxNlowgYAxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEQMA4GA1UEBxMHU0FO
Sk9TRTEPMA0GA1UEChMGTUFYWEFOMQwwCgYDVQQLEwNFTkcxDjAMBgNVBAMTBWNo
b25nMSMwIQYJKoZIhvcNAQkBFhRjaG9uZ3BlbmdAbWF4eGFuLmNvbTCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEAtEhf+CU6N18337D3jT24JWerM/3/5pVDvwlL
QfIZNA0891f/a4lmoK1R46mhf8YpFhbMW8ynnEcgwzcoYDFlfHngFRqSUr5siWR+
NzFjtcwogV7ItjEh6kACTn0/NN6k3N7Twm+ZOFCucrb8KUPGSMqJK50CUtBWCrKJ
39wEoysCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBX0jTsC73wXYHDhenL2piboCMQ
qF96W/YLShYJla3ipc8JG0GHStTjUY4w7KGjDJippRUhddv0CUAilD7EPYusr1oY
sk+Tt7QKCSLnued6NZwGnjIV78BmMi5gp5UEotgmPMk6Q6WKl0rVMbiJWqgy9f7b
Hk3SUgTCdn/T+ajIFQ==
-END CERTIFICATE-;
int serverKey(void)
{
BIO *bio;
if( (bio=BIO_new_mem_buf((void *)skey, sizeof(skey))) == NULL)
{
return(-1);
}
if( (pkey=PEM_read_bio_PrivateKey(bio, NULL, NULL, NULL)) == NULL)
{
BIO_free(bio);
return(-1);
}
BIO_free(bio);
return(0);
}
int serverCert(void)
{
BIO *bio;
if( (bio=BIO_new_mem_buf((void *)scert, sizeof(scert))) == NULL)
{
return(-1);
}
if( (cert=PEM_read_bio_X509(bio, NULL, NULL, NULL)) == NULL)
{
BIO_free(bio);
return(-1);
}
BIO_free(bio);
return(0);
}
this piece of code worked in the embedded system i am working on, hope this
helps.
chong peng
-Original Message-
From: Xie Grace Jingru-LJX001 [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 09, 2006 9:47 AM
To: openssl-users@openssl.org
Subject: Hard-coded keys and cert in the image
Re: Wildcard ssl certificate using subjectAltName
On Mon, Feb 13, 2006, Khai Doan wrote: Has anyone successfully create a double wildcard certificate (*.*.domain.com) ? Does it work with MSIE 6 XP service pack 2 ? Attached is my openssl.cnf, my test CSR, and my test certificate. Can you please see if anything wrong? Does anyone has a working certificate with subjectAltName that I can take a look ? You can successfully create one easily enough but it is unlikely to work. It is a violation of RFC3280 and probably wont be implemented in MSIE. I haven't tried it personally so there's an outside chance it might work. If you want to include multiple separate host names then that is legal and should work fine. I can't comment on the CSR and test certificate as the attachment doesn't seem to have been included... Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Wildcard ssl certificate using subjectAltName
For some reason Hotmail does not allow me to attach those files: Test CSR: -BEGIN CERTIFICATE REQUEST- MIICuzCCAiQCAQAwggF5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTESMBAGA1UEBxMJU2FuIE1hdGVvMRUwEwYDVQQKEwxHb3RHZW5pZS5jb20xFTAT BgNVBAsTDFRlY2hub2xvZ2llczEZMBcGA1UEAxQQKi4qLmdvdGdlbmllLmNvbTEX MBUGA1UEAxQOKi5nb3RnZW5pZS5jb20xFTATBgNVBAMTDGdvdGdlbmllLmNvbTEZ MBcGA1UdERQQKi4qLmdvdGdlbmllLmNvbTEXMBUGA1UdERQOKi5nb3RnZW5pZS5j b20xFTATBgNVHRETDGdvdGdlbmllLmNvbTEfMB0GCWCGSAGG+EIBDBQQKi4qLmdv dGdlbmllLmNvbTEdMBsGCWCGSAGG+EIBDBQOKi5nb3RnZW5pZS5jb20xGzAZBglg hkgBhvhCAQwTDGdvdGdlbmllLmNvbTEgMB4GCSqGSIb3DQEJARYRa2hhaUBnb3Rn ZW5pZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKZF+wX2nzE0Doh2 W6KJytKEu8CampAGptJmAIt2U2p5tCwLMXp7MS10cUOC4yFOL7Y6+Voyyo6UNO3H mVSSuZAWEs4hsOIK7lsFt1FYQxZ/XcaJfXrx3K9weaN/9ARco1p+QGIjJhHD/SLv xm7MPm5lFMCISIOjwP8+XZcp9fthAgMBAAGgADANBgkqhkiG9w0BAQQFAAOBgQAP incHoM4gXVC/BPfl1/o4XKmLlBzmIkmRZb+xhDHkxqEBnwF/jcm3OSpMDlIeYW3D lMMzb9sDOqpEGGZt0W/dIbL0OytBpPP+xcYy6PYXuwNlvef+if+W6U/0mTlkMvA5 R/+KWg9dpcirc7OssFyWNkIxVD62AFwQUltd0enbNw== -END CERTIFICATE REQUEST- Test certificates: Certificate: Data: Version: 3 (0x2) Serial Number: 12 (0xc) Signature Algorithm: md5WithRSAEncryption Issuer: C=US, ST=California, L=San Mateo, O=Genius Inc, OU=Technologies, CN=Genius Inc/[EMAIL PROTECTED] Validity Not Before: Feb 14 01:14:51 2006 GMT Not After : Feb 12 01:14:51 2016 GMT Subject: C=US, ST=California, L=San Mateo, O=GotGenie.com, OU=Technologies, CN=*.*.gotgenie.com, CN=*.gotgenie.com, CN=gotgenie.com/subjectAltName=*.*.gotgenie.com/subjectAltName=*.gotgenie.com/subjectAltName=gotgenie.com/nsSslServerName=*.*.gotgenie.com/nsSslServerName=*.gotgenie.com/nsSslServerName=gotgenie.com/[EMAIL PROTECTED] Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:a6:45:fb:05:f6:9f:31:34:0e:88:76:5b:a2:89: ca:d2:84:bb:c0:9a:9a:90:06:a6:d2:66:00:8b:76: 53:6a:79:b4:2c:0b:31:7a:7b:31:2d:74:71:43:82: e3:21:4e:2f:b6:3a:f9:5a:32:ca:8e:94:34:ed:c7: 99:54:92:b9:90:16:12:ce:21:b0:e2:0a:ee:5b:05: b7:51:58:43:16:7f:5d:c6:89:7d:7a:f1:dc:af:70: 79:a3:7f:f4:04:5c:a3:5a:7e:40:62:23:26:11:c3: fd:22:ef:c6:6e:cc:3e:6e:65:14:c0:88:48:83:a3: c0:ff:3e:5d:97:29:f5:fb:61 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: C7:C5:2B:56:F0:9C:48:E3:6C:C6:84:24:0C:C9:85:F9:CA:49:C2:40 X509v3 Authority Key Identifier: keyid:48:A3:D0:A4:B7:CB:62:71:54:49:EF:04:B6:D6:96:BF:3C:BB:3E:D5 DirName:/C=US/ST=California/L=San Mateo/O=Genius Inc/OU=Technologies/CN=Genius Inc/[EMAIL PROTECTED] serial:00 Signature Algorithm: md5WithRSAEncryption 9b:c4:aa:b0:8f:d0:bc:2d:b6:f2:6c:c4:4d:c1:6f:c2:46:88: 4e:d8:95:95:21:c0:36:f1:a8:0f:9d:ee:3a:44:ad:35:ac:dd: 12:b6:0a:3f:09:47:c0:d0:ca:be:27:31:97:ff:a7:37:44:00: a1:ce:a4:c8:7f:2f:19:77:1c:ce:cf:9a:17:17:6a:52:40:8c: 2a:10:9b:a5:21:d5:30:1b:5b:38:22:88:f9:fe:82:89:5e:15: 9a:df:06:3f:e7:2a:d2:a6:6b:8c:02:f7:9a:c6:72:7d:25:e7: eb:8c:ef:f1:65:8e:96:a1:87:8b:64:c1:31:e6:b1:4b:10:3b: bb:da -BEGIN CERTIFICATE- MIIErjCCBBegAwIBAgIBDDANBgkqhkiG9w0BAQQFADCBlzELMAkGA1UEBhMCVVMx EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVNhbiBNYXRlbzETMBEGA1UE ChMKR2VuaXVzIEluYzEVMBMGA1UECxMMVGVjaG5vbG9naWVzMRMwEQYDVQQDEwpH ZW5pdXMgSW5jMR4wHAYJKoZIhvcNAQkBFg9raGFpQGdlbml1cy5jb20wHhcNMDYw MjE0MDExNDUxWhcNMTYwMjEyMDExNDUxWjCCAXkxCzAJBgNVBAYTAlVTMRMwEQYD VQQIEwpDYWxpZm9ybmlhMRIwEAYDVQQHEwlTYW4gTWF0ZW8xFTATBgNVBAoTDEdv dEdlbmllLmNvbTEVMBMGA1UECxMMVGVjaG5vbG9naWVzMRkwFwYDVQQDFBAqLiou Z290Z2VuaWUuY29tMRcwFQYDVQQDFA4qLmdvdGdlbmllLmNvbTEVMBMGA1UEAxMM Z290Z2VuaWUuY29tMRkwFwYDVR0RFBAqLiouZ290Z2VuaWUuY29tMRcwFQYDVR0R FA4qLmdvdGdlbmllLmNvbTEVMBMGA1UdERMMZ290Z2VuaWUuY29tMR8wHQYJYIZI AYb4QgEMFBAqLiouZ290Z2VuaWUuY29tMR0wGwYJYIZIAYb4QgEMFA4qLmdvdGdl bmllLmNvbTEbMBkGCWCGSAGG+EIBDBMMZ290Z2VuaWUuY29tMSAwHgYJKoZIhvcN AQkBFhFraGFpQGdvdGdlbmllLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEApkX7BfafMTQOiHZboonK0oS7wJqakAam0mYAi3ZTanm0LAsxensxLXRxQ4Lj IU4vtjr5WjLKjpQ07ceZVJK5kBYSziGw4gruWwW3UVhDFn9dxol9evHcr3B5o3/0 BFyjWn5AYiMmEcP9Iu/Gbsw+bmUUwIhIg6PA/z5dlyn1+2ECAwEAAaOCASMwggEf MAkGA1UdEwQCMAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENl cnRpZmljYXRlMB0GA1UdDgQWBBTHxStW8JxI42zGhCQMyYX5yknCQDCBxAYDVR0j BIG8MIG5gBRIo9Ckt8ticVRJ7wS21pa/PLs+1aGBnaSBmjCBlzELMAkGA1UEBhMC VVMxEzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVNhbiBNYXRlbzETMBEG A1UEChMKR2VuaXVzIEluYzEVMBMGA1UECxMMVGVjaG5vbG9naWVzMRMwEQYDVQQD
Re: Wildcard ssl certificate using subjectAltName
On Mon, Feb 13, 2006, Khai Doan wrote: For some reason Hotmail does not allow me to attach those files: Test CSR: -BEGIN CERTIFICATE REQUEST- MIICuzCCAiQCAQAwggF5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTESMBAGA1UEBxMJU2FuIE1hdGVvMRUwEwYDVQQKEwxHb3RHZW5pZS5jb20xFTAT BgNVBAsTDFRlY2hub2xvZ2llczEZMBcGA1UEAxQQKi4qLmdvdGdlbmllLmNvbTEX MBUGA1UEAxQOKi5nb3RnZW5pZS5jb20xFTATBgNVBAMTDGdvdGdlbmllLmNvbTEZ MBcGA1UdERQQKi4qLmdvdGdlbmllLmNvbTEXMBUGA1UdERQOKi5nb3RnZW5pZS5j b20xFTATBgNVHRETDGdvdGdlbmllLmNvbTEfMB0GCWCGSAGG+EIBDBQQKi4qLmdv dGdlbmllLmNvbTEdMBsGCWCGSAGG+EIBDBQOKi5nb3RnZW5pZS5jb20xGzAZBglg hkgBhvhCAQwTDGdvdGdlbmllLmNvbTEgMB4GCSqGSIb3DQEJARYRa2hhaUBnb3Rn ZW5pZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKZF+wX2nzE0Doh2 W6KJytKEu8CampAGptJmAIt2U2p5tCwLMXp7MS10cUOC4yFOL7Y6+Voyyo6UNO3H mVSSuZAWEs4hsOIK7lsFt1FYQxZ/XcaJfXrx3K9weaN/9ARco1p+QGIjJhHD/SLv xm7MPm5lFMCISIOjwP8+XZcp9fthAgMBAAGgADANBgkqhkiG9w0BAQQFAAOBgQAP incHoM4gXVC/BPfl1/o4XKmLlBzmIkmRZb+xhDHkxqEBnwF/jcm3OSpMDlIeYW3D lMMzb9sDOqpEGGZt0W/dIbL0OytBpPP+xcYy6PYXuwNlvef+if+W6U/0mTlkMvA5 R/+KWg9dpcirc7OssFyWNkIxVD62AFwQUltd0enbNw== -END CERTIFICATE REQUEST- Test certificates: Certificate: Data: Version: 3 (0x2) Serial Number: 12 (0xc) Signature Algorithm: md5WithRSAEncryption Issuer: C=US, ST=California, L=San Mateo, O=Genius Inc, OU=Technologies, CN=Genius Inc/[EMAIL PROTECTED] Validity Not Before: Feb 14 01:14:51 2006 GMT Not After : Feb 12 01:14:51 2016 GMT Subject: C=US, ST=California, L=San Mateo, O=GotGenie.com, OU=Technologies, CN=*.*.gotgenie.com, CN=*.gotgenie.com, CN=gotgenie.com/subjectAltName=*.*.gotgenie.com/subjectAltName=*.gotgenie.com/subjectAltName=gotgenie.com/nsSslServerName=*.*.gotgenie.com/nsSslServerName=*.gotgenie.com/nsSslServerName=gotgenie.com/[EMAIL PROTECTED] Well you've put subjectAltName in the *subject* name. It should go in the extensions part. Look at: http://www.openssl.org/docs/apps/x509v3_config.html#Subject_Alternative_Name_ you need something like: subjectAltName = DNS:whatever.hostname.com in the certificate extensions section. Then the extension will appear when the certificate is signed. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Wildcard ssl certificate using subjectAltName
Can I have subjectAltName = critical,DNS:*.hostname.com What other things are possible here (DNS, IP, email, URI, etc) ? Using IP:192.168.10.16 and DNS:*.hostname.com does not seems to work (Internet Explorer throw up a warning dialog: The name on the security certificates is invalid or does not match the name of the site). Has anyone successfully create a wild card certificate that bind to an IP address ? Thanks Khai From: Dr. Stephen Henson [EMAIL PROTECTED] Reply-To: openssl-users@openssl.org To: openssl-users@openssl.org Subject: Re: Wildcard ssl certificate using subjectAltName Date: Tue, 14 Feb 2006 04:23:03 +0100 On Mon, Feb 13, 2006, Khai Doan wrote: For some reason Hotmail does not allow me to attach those files: Test CSR: -BEGIN CERTIFICATE REQUEST- MIICuzCCAiQCAQAwggF5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTESMBAGA1UEBxMJU2FuIE1hdGVvMRUwEwYDVQQKEwxHb3RHZW5pZS5jb20xFTAT BgNVBAsTDFRlY2hub2xvZ2llczEZMBcGA1UEAxQQKi4qLmdvdGdlbmllLmNvbTEX MBUGA1UEAxQOKi5nb3RnZW5pZS5jb20xFTATBgNVBAMTDGdvdGdlbmllLmNvbTEZ MBcGA1UdERQQKi4qLmdvdGdlbmllLmNvbTEXMBUGA1UdERQOKi5nb3RnZW5pZS5j b20xFTATBgNVHRETDGdvdGdlbmllLmNvbTEfMB0GCWCGSAGG+EIBDBQQKi4qLmdv dGdlbmllLmNvbTEdMBsGCWCGSAGG+EIBDBQOKi5nb3RnZW5pZS5jb20xGzAZBglg hkgBhvhCAQwTDGdvdGdlbmllLmNvbTEgMB4GCSqGSIb3DQEJARYRa2hhaUBnb3Rn ZW5pZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKZF+wX2nzE0Doh2 W6KJytKEu8CampAGptJmAIt2U2p5tCwLMXp7MS10cUOC4yFOL7Y6+Voyyo6UNO3H mVSSuZAWEs4hsOIK7lsFt1FYQxZ/XcaJfXrx3K9weaN/9ARco1p+QGIjJhHD/SLv xm7MPm5lFMCISIOjwP8+XZcp9fthAgMBAAGgADANBgkqhkiG9w0BAQQFAAOBgQAP incHoM4gXVC/BPfl1/o4XKmLlBzmIkmRZb+xhDHkxqEBnwF/jcm3OSpMDlIeYW3D lMMzb9sDOqpEGGZt0W/dIbL0OytBpPP+xcYy6PYXuwNlvef+if+W6U/0mTlkMvA5 R/+KWg9dpcirc7OssFyWNkIxVD62AFwQUltd0enbNw== -END CERTIFICATE REQUEST- Test certificates: Certificate: Data: Version: 3 (0x2) Serial Number: 12 (0xc) Signature Algorithm: md5WithRSAEncryption Issuer: C=US, ST=California, L=San Mateo, O=Genius Inc, OU=Technologies, CN=Genius Inc/[EMAIL PROTECTED] Validity Not Before: Feb 14 01:14:51 2006 GMT Not After : Feb 12 01:14:51 2016 GMT Subject: C=US, ST=California, L=San Mateo, O=GotGenie.com, OU=Technologies, CN=*.*.gotgenie.com, CN=*.gotgenie.com, CN=gotgenie.com/subjectAltName=*.*.gotgenie.com/subjectAltName=*.gotgenie.com/subjectAltName=gotgenie.com/nsSslServerName=*.*.gotgenie.com/nsSslServerName=*.gotgenie.com/nsSslServerName=gotgenie.com/[EMAIL PROTECTED] Well you've put subjectAltName in the *subject* name. It should go in the extensions part. Look at: http://www.openssl.org/docs/apps/x509v3_config.html#Subject_Alternative_Name_ you need something like: subjectAltName = DNS:whatever.hostname.com in the certificate extensions section. Then the extension will appear when the certificate is signed. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
