Hi, people
I was tinkering with some piece of code (modified from /demos/selfsign)
and I was shocked to find that I saw a private key where
I shouldn't. Here is the code
CODE
=
#include stdio.h
#include stdlib.h
#include openssl/pem.h
#include openssl/conf.h
#include openssl/x509v3.h
rrln wrote:
I was tinkering with some piece of code (modified from /demos/selfsign)
and I was shocked to find that I saw a private key where
I shouldn't. Here is the code
I might be missing the point here, but the following calls look pretty
explicit to me:
Hi,
I suppose you should tell apache and your navigator where is your CA
certificate,
For apache, i think you can tell him with by the httpsd.conf directives:
SSLCACertificatePath -- points to verification path
SSLCACertificateFile -- points to CA [selfsigned] certificate
You also can
You can refer to www.apache-ssl.com, or to recent
archives of this list.
Hazel
--- greg zhang [EMAIL PROTECTED] wrote:
Hi All,
I am new openssl.
I set up a apache server with openssl feature.
But I don't understand how to produce a certificate.
I do "make certificate" get a failed
rrln wrote:
Hi, people
I was tinkering with some piece of code (modified from /demos/selfsign)
and I was shocked to find that I saw a private key where
I shouldn't. Here is the code
[stuff deleted]
It seems that the call to X509_print_fp() is showing the private key. I
thought that
I'm trying to use the sconnect-demo with Win32 but
it does not work - the system crashes. (V 0.9.5)
I found bugs:
1) the internal random generator is not initialized
in the sample and writes some internal error messages.
2)The function ERR_print_errors_fp() (file err_prn.c) in
the sample
apologies for the open-ssl list for the repost. i want to make sure that
the patch below is correct.
a couple of months ago jean-luc rochat told me how to patch jserv to
relay client digital certificates to servlets. yesterday, with help of
ben laurie, i made jserv to do the same with
rrln It seems that the call to X509_print_fp() is showing the private key. I
rrln thought that X509_set_pubkey() only take the public part of the RSA key
rrln
rrln to the X509 structure, but it seems that it puts all the key .
rrln
rrln When I cut the PEM code ( BEGIN CERTIFICATE --- END
rrln wrote:
That's right, and that was expected, but what bothers me is that a call to
X509_print_fp() is showing private key info.
You're right of course, and I should know better than to post after
sitting up half the night playing drunken Need For Speed: Porsche
Challenge.
I think Stephen
rrln wrote:
That's right, and that was expected, but what bothers me is that a call to
X509_print_fp() is showing private key info.
Since this issue crops up quite often and it is a potential security
risk (e.g. using the -text option when a certificate or request has just
been signed)
Hi
we plan to use the PKCS#7 module to signt + encrypt data.
In the readme file of the crypto/pkcs7 directory we can read:
"WARNING
Everything in this directory is experimental and is subject to
change.
Do not rely on the stuff in here not changing in the next release"
I'd be very grateful
Hi,
I have another newbie question.
I'm using RSA_verify to verify a signature which synopsis according to the OpenSSL
webpage documentation if following:
int RSA_verify(int type, unsigned char *m, unsigned int m_len,
unsigned char *sigbuf, unsigned int siglen, RSA *rsa);
and i've been
Is this an error in documentation? According to Applied Crypto,
Schneier, p 194, the IV in CBC mode ciphers should be different for
each message. Looking at the source for BF_cbc_encrypt(), it looks
like iv can be initialized with any 64 bytes.
from the blowfish(3) man page
Richard Dykiel wrote:
Hi
we plan to use the PKCS#7 module to signt + encrypt data.
In the readme file of the crypto/pkcs7 directory we can read:
"WARNING
Everything in this directory is experimental and is subject to change.
Do not rely on the stuff in here not changing in the next
At 19:24 22.03.00 +0200, you wrote:
Hi,
I have another newbie question.
I'm using RSA_verify to verify a signature which synopsis according to the
OpenSSL webpage documentation if following:
int RSA_verify(int type, unsigned char *m, unsigned int m_len,
unsigned char *sigbuf, unsigned int
noel Is this an error in documentation? According to Applied Crypto,
noel Schneier, p 194, the IV in CBC mode ciphers should be different for
noel each message. Looking at the source for BF_cbc_encrypt(), it looks
noel like iv can be initialized with any 64 bytes.
You're right, that is a
OpenSSL was built with "no-rsa no-idea no-rc2 no-rc4 no-rc5 -DSSL_ALLOW_ADH".
I then built stunnel it complained about the following symbols.
Undefined first referenced
symbol in file
ssl2_clear
I'm trying to generate a test certificate on my Solaris 7 box as explained
in the README.SSL that came with Apache 1.3.12 + SSL and getting;
% make certificate
/tmp/bg/openssl-SNAP-2321/apps/openssl req -config
../SSLconf/conf/ssleay.cnf \
-new -x509 -nodes -out ../SSLconf/conf/httpsd.pem \
During the process of creating your own CA, you came up with a 'ca.crt'
file (the FIRST .crt file that you came up with). You need to download
this into your client, as a specific MIME type.
(application/x-x509-certificate)
For MSIE, it requires it to be sent in .der format, which is
My question is, how's a typical authentication delegation implemented
using SSL? I can visualize a point-to-point authetication happening between
the client and ServiceA. But, how can I control access to ServiceB's
resources by ServiceA unless ServiceA is acting on behalf of a authorised
Hi
I hope I'm not just doing something stupid.
I run the following:
./configure --prefix=/usr/local/openssh --with-ssl-dir=/usr/local/ssl
also tried --with-ssl-dir=/usr/local/ssl/lib
/usr/local/ssl/lib contains 2 files: libcrypto.a and libssl.a
configure fails with the error that it "Could
"Wilder, John" wrote:
The openssl has utilities to generate DSA and RSA encrypted keys.
Is there anyway to generate 56bit DES keys? If not by openssl, how?
Just pick a random number.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
22 matches
Mail list logo
