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
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]
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
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
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
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
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
--- 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
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
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.
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
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
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
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
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
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
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
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
List,
Has anyone used OpenSSL to create EFS certificates? Any
recommendations on using OpenSSL to create EFS certificates will be greatly
appreciated.
Regards,
David
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
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
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
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()
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
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
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
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
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,
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:
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
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
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
For some reason Hotmail does not allow me to attach those files:
Test CSR:
-BEGIN CERTIFICATE REQUEST-
MIICuzCCAiQCAQAwggF5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p
YTESMBAGA1UEBxMJU2FuIE1hdGVvMRUwEwYDVQQKEwxHb3RHZW5pZS5jb20xFTAT
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
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
35 matches
Mail list logo
