Re: Certificate Revocation List (CRL) management recommendations?
Jorey Bump wrote: I'm nearly complete in setting up my own CA, but I'm not sure how to manage Certificate Revocation Lists (CRL). I noticed that related settings such as *RevocationUrl are commented out in the default openssl.cnf. Should I fill these in and post my CRL, or should I just make default_crl_days = default_days? FWIW, the CA will be used mainly for signing certificates for intranet HTTPS web servers and STARTTLS mail servers. The root CA certificate will be installed in browsers and mail clients to suppress the warnings about self signed certificates. The idea behind a CRL is to have the possibility to publicly revoke a certificate before it expires (so setting default_crl_days equal to default days is not very sensible, you should just work without a CRL in such a case). The disadvantage of a CRL is that it has to be accessible and kept up-to-date or the verification will fail. So using a CRL will require a stable net, stable webserver and someone (possibly a cron job or something like that) generating new CRLs in regular intervals. Wether you can do without a CRL is hard to say without knowing your detailed security requirements. If there are only few servers to distribute new certificates to, setting a shorter expiry date may do a similar job. On the other hand, if you are using the certificates for client access to important data you might like to be able to revoke a lost certificate within few days or even hours, in which case even a CRL might not be fast enough and you'd have to set up an OCSP server... Just consider what might happen if a certificate is compromised and used by someone evil till it expires, this will help you to decide. Hope it helps, Ted ;) -- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 smime.p7s Description: S/MIME Cryptographic Signature
Re: OpenSSL 0.9.8 with AIX 5.2
Tom Spence a écrit : Hello, I have very small problem but it won't running... Please help me... Here is what I got: # ./Configure aix-gcc (no problem) # make gcc -I.. -I../.. -I../../include -DOPENSSL_THREADS -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -O -DB_ENDIAN -c -o aix_ppc32.o aix_ppc32.s (It stops right there for forever) Any idea??? I appreciate your help. Thanks. I could not find a way to successfully build OpenSSL (at least from version 0.9.7g) without using IBM's C/C++ compiler :-( -- Mr. Jacques LEBASTARDmailto:[EMAIL PROTECTED] EVIDIAN S.A. www.evidian.com Rue Jean Jaurès Tel: +33 1 30 80 77 86 F-78340 LES CLAYES SOUS BOIS Fax: +33 1 30 80 77 99 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: HTTPS
Thank you Ted. It compiles now. : How can I set client certificate for SSL connection? I keep cert in sslclient.pfx file. Best regards, Milan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernhard Froehlich Sent: Friday, July 15, 2005 1:29 PM To: openssl-users@openssl.org Subject: Re: HTTPS Milan Tomic wrote: Can cli.cpp run on Windows platform? I need Windows OpenSSL HTTPS client. While compiling I got an error saying that it can't find sys/socket.h include file. Thank you. Uhh, hard times ahead if you want to code SSL and ask me such questions... ;) I guess you'll need the following headers: #include windows.h #include winsock.h #include stdio.h #include stdlib.h plus the openssl-headers : #include openssl/crypto.h #include openssl/x509.h #include openssl/pem.h #include openssl/ssl.h #include openssl/err.h to compile cli.cpp. Maybe perror still gives you trouble, just replace it with printf. If it does not find any of the headers try to kick out the include-statement and if you get compile errors check your compiler's documentation for the file to include for the missing functions. Hope it helps Ted ;) -- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL 0.9.8 with AIX 5.2
I have but, it has been awhile. I was able to do it under AIX 5.1 and I ran configure using custom options. They are: ./config no-idea no-threads -fPIC The original system that was running 5.1 is now upgraded to 5.3 and have to switch to the IBM C/C++ compiler due to no gcc compiler being available last time I checked 4 months ago. Paul Franz -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacques Lebastard Sent: Monday, July 18, 2005 3:07 AM To: openssl-users@openssl.org Subject: [Glog_SPAM]Re: OpenSSL 0.9.8 with AIX 5.2 Tom Spence a écrit : Hello, I have very small problem but it won't running... Please help me... Here is what I got: # ./Configure aix-gcc (no problem) # make gcc -I.. -I../.. -I../../include -DOPENSSL_THREADS -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -O -DB_ENDIAN -c -o aix_ppc32.o aix_ppc32.s (It stops right there for forever) Any idea??? I appreciate your help. Thanks. I could not find a way to successfully build OpenSSL (at least from version 0.9.7g) without using IBM's C/C++ compiler :-( -- Mr. Jacques LEBASTARDmailto:[EMAIL PROTECTED] EVIDIAN S.A. www.evidian.com Rue Jean Jaurès Tel: +33 1 30 80 77 86 F-78340 LES CLAYES SOUS BOIS Fax: +33 1 30 80 77 99 __ 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: OpenSSL 0.9.8 with AIX 5.2
Excatly!!! That's why, I can't use OpenSSL 0.9.8 so I have to stay with 0.9.7g for now. But I don't understand this one... I have 21 servers... Only one server (AIX 5.2 with GCC) accepted with OpenSSL 0.9.8 but 20 servers can't... Isn't strange? :-( TomJacques Lebastard [EMAIL PROTECTED] wrote: Tom Spence a écrit : Hello, I have very small problem but it won't running... Please help me... Here is what I got: # ./Configure aix-gcc (no problem) # make gcc -I.. -I../.. -I../../include -DOPENSSL_THREADS -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -O -DB_ENDIAN -c -o aix_ppc32.o aix_ppc32.s (It stops right there for forever) Any idea??? I appreciate your help. Thanks.I could not find a way to successfully build OpenSSL (at least from version 0.9.7g) without using IBM's C/C++ compiler :-(-- Mr. Jacques LEBASTARD mailto:[EMAIL PROTECTED]EVIDIAN S.A. www.evidian.comRue Jean Jaurès Tel: +33 1 30 80 77 86F-78340 LES CLAYES SOUS BOIS Fax: +33 1 30 80 77 99__OpenSSL Project http://www.openssl.orgUser Support Mailing List openssl-users@openssl.orgAutomated List Manager [EMAIL PROTECTED] (__[TomCigar]___~~~
PKCS12_parse() fails (0.9.8.)
Title: PKCS12_parse() fails (0.9.8.) PKCS12_parse() fails (returns 0) in my case, although PKCS12_verify_mac() succeed (return 1). I have tried to export cert key into .pfx file in two ways: - using Internet Explorer GUI, - using java's keytool. but still the same. What should I do? :(
RE: OpenSSL 0.9.8 with AIX 5.2
BTW, that was for compiling 0.9.7e -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Franz, Paul Sent: Monday, July 18, 2005 6:16 AM To: openssl-users@openssl.org Subject: Re: OpenSSL 0.9.8 with AIX 5.2 I have but, it has been awhile. I was able to do it under AIX 5.1 and I ran configure using custom options. They are: ./config no-idea no-threads -fPIC The original system that was running 5.1 is now upgraded to 5.3 and have to switch to the IBM C/C++ compiler due to no gcc compiler being available last time I checked 4 months ago. Paul Franz -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacques Lebastard Sent: Monday, July 18, 2005 3:07 AM To: openssl-users@openssl.org Subject: [Glog_SPAM]Re: OpenSSL 0.9.8 with AIX 5.2 Tom Spence a écrit : Hello, I have very small problem but it won't running... Please help me... Here is what I got: # ./Configure aix-gcc (no problem) # make gcc -I.. -I../.. -I../../include -DOPENSSL_THREADS -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -O -DB_ENDIAN -c -o aix_ppc32.o aix_ppc32.s (It stops right there for forever) Any idea??? I appreciate your help. Thanks. I could not find a way to successfully build OpenSSL (at least from version 0.9.7g) without using IBM's C/C++ compiler :-( -- Mr. Jacques LEBASTARDmailto:[EMAIL PROTECTED] EVIDIAN S.A. www.evidian.com Rue Jean Jaurès Tel: +33 1 30 80 77 86 F-78340 LES CLAYES SOUS BOIS Fax: +33 1 30 80 77 99 __ 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: Investigating a leak
http://www.openssl.org/support/faq.html Search for the words *memory leak* -Amar. Axel Andersson wrote: Hello, I'm investigating a leak in a server application, which I've managed to reduce to a test case which involves OpenSSL and threads. I've put the code up at http://www.zankasoftware.com/ssltest/server.c if anyone would be willing to take a look and see what I'm doing wrong. Every time I connect to this test with openssl s_client, it leaks some 516 KB virtual memory, which is never reclaimed. If pthread_join () is inserted after pthread_create(), no leaks occur. It does not matter if I move all the SSL calls to the reply thread, or leave the SSL_accept() call in the main thread where it is now. I'm testing this on Mac OS X with its default OpenSSL 0.9.7b. I also downloaded and built the recent 0.9.8 release and was able to reproduce the problem with that. Thanks in advance, -- Axel __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: Certificate Revocation List (CRL) management recommendations?
Bernhard Froehlich wrote: The idea behind a CRL is to have the possibility to publicly revoke a certificate before it expires (so setting default_crl_days equal to default days is not very sensible, you should just work without a CRL in such a case). Is this as simple as commenting out default_crl_days? I've noticed that a certificate with a longer default_days will be treated as expired when default_crl_days is reached. Yet, I don't see the CRL period in the signed certificate when I view it with the -text option. I'm afraid I don't understand the underlying CRL checking mechanism. Does the server (web, mail, etc.) check the CRL, or the client? It's been mentioned elsewhere that the CRLs of major CAs can grow to be several MB, but I can't say that I've ever noticed such activity on either my servers or clients (not that I was looking for it, but I do actively monitor connections). The disadvantage of a CRL is that it has to be accessible and kept up-to-date or the verification will fail. So using a CRL will require a stable net, stable webserver and someone (possibly a cron job or something like that) generating new CRLs in regular intervals. I can probably do that, although at the moment it would seem more manageable to push the CRL out to the small number of clients when necessary. On the other hand, it seems that simply replacing a certificate on the server is as effective as revoking it and publishing a CRL (assuming, of course, that noone has acquired the key/cert and is using it to masquerade as my server). In this case, a CRL would be most valuable in protecting the integrity of my root CA certificate (which could also be replaced and redistributed, I guess). Wether you can do without a CRL is hard to say without knowing your detailed security requirements. If there are only few servers to distribute new certificates to, setting a shorter expiry date may do a similar job. On the other hand, if you are using the certificates for client access to important data you might like to be able to revoke a lost certificate within few days or even hours, in which case even a CRL might not be fast enough and you'd have to set up an OCSP server... Yes, I've glanced at OCSP, and it seems to be the most sensible approach. But is it widely supported? Is the OCSP server included with OpenSSL robust? Is it recommended to set up OCSP servers on port 80 to accommodate corporate firewalls? I have no current plans for issuing client certificates, but the need may arise in the future. Just consider what might happen if a certificate is compromised and used by someone evil till it expires, this will help you to decide. Evil people suck. :) I understand the significance of asking users to import my root CA certificate (as opposed to simply accepting the server certificate for each session) and I want to protect them from my own oversight, as well. My next step will be to learn how to narrow the purpose of a certificate when I sign it. Hope it helps, Yes, it does. A few days ago I thought SSL/TLS was hopelessly complex, but now I'm sure of it. :) In any case, I've made some great gains and I'm at the point of trying to determine what standard practice is. Inspecting other root CA certificates is of little help because they vary so wildly according to their purpose. There are a lot of features I'll probably never use, but I wonder if some of them are ignored by everyone, due to lack of server/client support. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Max length of serial number
Jorey Bump wrote: There is one caveat: the number of characters must be even: unable to load number from /etc/ssl/CA/serial error while loading serial number 3068:error:0D066091:asn1 encoding routines:a2i_ASN1_INTEGER:odd number of chars:f_int.c:162: Therefore, I needed to modify my command: # example: 2005071711520001 (16 char, must be even # of chars) echo $(date +%Y%m%d%H%M)0001 serial And RFC 3280 has this to say: 4.1.2.2 Serial number The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). CAs MUST force the serialNumber to be a non-negative integer. Given the uniqueness requirements above, serial numbers can be expected to contain long integers. Certificate users MUST be able to handle serialNumber values up to 20 octets. Conformant CAs MUST NOT use serialNumber values longer than 20 octets. Note: Non-conforming CAs may issue certificates with serial numbers that are negative, or zero. Certificate users SHOULD be prepared to gracefully handle such certificates. I guess this limits serial numbers to 20 numeric characters, and I assume this includes leading zeroes, unless the asn1 encoding routine strips them. Unfortunately, this limits the life of my CA to 99,997,994,928,288,479,998 signed certficates, using the example I've given above. ;) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
OpenSSL on W32
We have an Apache web server installed on a Windows server. We are trying to get SSL to work on this site but have been unsuccessful. We created the certificate file and have received our key file from Verisign. We have downloaded OpenSSL. First, where can I find the install.w32 instructions? Maybe this will help. Can someone guide me with the basic steps? Do I need to compile a module or modules into the Apache server? If so which ones? Any help would be greatly appreciated. Dan Buckland Director Applications Support Hickory Farms 419-893-7611 ext 248
Re: Investigating a leak
On Jul 18, 2005, at 14:11, Amar Desai wrote: http://www.openssl.org/support/faq.html Search for the words *memory leak* Yes, thank you, indeed I have read that, and I am using ERR_remove_state() at the end of the thread. Looks to me like the other functions should be used before terminating the application, not for per-thread cleanup, or did I misunderstand something? -- Axel __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Is OpenSSL Thread-Safe
Hi, I have a question regarding how to compile Openssl to make it thread safe. What MACROS have to be enabled for this. Regards Suram __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: AW: Max length of serial number
[EMAIL PROTECTED] writes: as far as I read the text from the RFC, they are talkin about non-negative numbers. So the range is from 0 to 2^(159)-1 because the one bit missing indicates a negative number. True. That doesn't change my point, though :-). Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Investigating a leak
Yes, You need to call other functions as well. -Amar Axel Andersson wrote: Yes, thank you, indeed I have read that, and I am using ERR_remove_state() at the end of the thread. Looks to me like the other functions should be used before terminating the application, not for per-thread cleanup, or did I misunderstand something? -- Axel __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
RE: Investigating a leak
Hi Axel, I don't know if it helps you much, but since the FAQ is a bit cryptic it may help. I've used... ERR_remove_state() ...at the end of each thread. Plus... CRYPTO_cleanup_all_ex_data() CONF_modules_free() ERR_free_strings() EVP_cleanup() ... at the end of the application. I have no leaks that I can detect when using 0.9.7g. At the time I wrote my code I couldn't find any FAQ entry that worked along the lines of if you use function or function group , then you must call to free underlying data. My app' isn't loading external engines or doing anything fancy, so these are probably not a comprehensive list of resource releasing functions. Regards, Simon - -- Simon Edwards -Original Message- From: Amar Desai [mailto:[EMAIL PROTECTED] Sent: 18 July 2005 16:59 To: openssl-users@openssl.org Subject: Re: Investigating a leak Yes, You need to call other functions as well. -Amar Axel Andersson wrote: Yes, thank you, indeed I have read that, and I am using ERR_remove_state() at the end of the thread. Looks to me like the other functions should be used before terminating the application, not for per-thread cleanup, or did I misunderstand something? -- Axel __ 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]
d2i_RSAPublicKey doesn't work
Title: d2i_RSAPublicKey doesn't work
What am I doing wrong here? I generate an RSA key. Then I DER encode it. Then try to decode it, but the decode fails. The error says, error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long
RSA* rsa = RSA_generate_key(2048, RSA_F4, 0, 0);
if (rsa)
{
if (RSA_check_key(rsa) 0)
{
int len = i2d_RSAPublicKey(rsa, 0);
U8* buf = new U8[len];
memset(buf, 0, len);
i2d_RSAPublicKey(rsa, buf);
// everything looks good up to here; I can see buf gets filled with len number of bytes
// but then I try to get the public key back by doing the following, and it fails.
RSA* public_key = d2i_RSAPublicKey(0, (const U8**)buf, len); // public_key is NULL; why???
if (!public_key)
{
char err[1024];
ERR_error_string(ERR_get_error(), err);
fprintf(stderr, Error : %s\n, err);
}
}
}
Re: Investigating a leak
On Jul 18, 2005, at 18:57, Simon Edwards wrote: I don't know if it helps you much, but since the FAQ is a bit cryptic it may help. I've used... ERR_remove_state() ...at the end of each thread. Doing this. Plus... CRYPTO_cleanup_all_ex_data() CONF_modules_free() ERR_free_strings() EVP_cleanup() ... at the end of the application. Doing this now, but since my app is a server, it never really reaches the end, and the leaks build up during its lifetime, which I'd rather hoped could be more than a day or so. As it is now, the process' virtual memory size quickly reaches 3.5 GB, and then malloc() starts failing. Well, thanks for your help anyway, I appreciate it. -- Axel __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Certificate Revocation List (CRL) management recommendations?
Bernhard Froehlich wrote: Jorey Bump wrote: Is this as simple as commenting out default_crl_days? I've noticed that a certificate with a longer default_days will be treated as expired when default_crl_days is reached. Yet, I don't see the CRL period in the signed certificate when I view it with the -text option. I'm afraid I don't understand the underlying CRL checking mechanism. Does the server (web, mail, etc.) check the CRL, or the client? No, you have to comment out crlDistributionPoints (and maybe some similar entries like nsCaRevocationUrl). If a crlDistributionPoint is coded into the certificate a verifying entity should download a new CRL every default_crl_days days, and if it is not possible to download the CRL (maybe because you forgot to publish the current version) the verification should fail! Otherwise an evil guy would swamp the CRL distribution point with DoS-attacks and could use a revoked cert till its expiry date. Thanks a lot for the clarification. I've learned a lot over the last few days - enough to realize that I misinterpreted some of the failures. OK, if someone acquired your CA's key you're deep in the dirt, regardless wether you use CRLs or not, since the evil one can build his/her own CRLs with the signature of your CA. ;) But only with the passphrase of the CA private key, correct? I don't know very much about OCSP since I haven't used it till now. As I understand it it's a webserver-plugin (cgi or perl or something like that) that looks up a certificate's serial number in its local CRL and returns (essentially) TRUE or FALSE. It'll never catch on -- too effecient. :) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: d2i_RSAPublicKey doesn't work
Edward Chan wrote:
What am I doing wrong here? I generate an RSA key. Then I DER encode
it. Then try to decode it, but the decode fails. The error says,
error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long
RSA* rsa = RSA_generate_key(2048, RSA_F4, 0, 0);
if (rsa)
{
if (RSA_check_key(rsa) 0)
{
int len = i2d_RSAPublicKey(rsa, 0);
U8* buf = new U8[len];
memset(buf, 0, len);
i2d_RSAPublicKey(rsa, buf);
// everything looks good up to here; I can see buf gets
filled with len number of bytes
// but then I try to get the public key back by doing
the following, and it fails.
RSA* public_key = d2i_RSAPublicKey(0, (const U8**)buf,
len); // public_key is NULL; why???
if (!public_key)
{
char err[1024];
ERR_error_string(ERR_get_error(), err);
fprintf(stderr, Error : %s\n, err);
}
}
}
please read the FAQ
Nils
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Certificate Revocation List (CRL) management recommendations?
Jorey Bump wrote: Bernhard Froehlich wrote: The idea behind a CRL is to have the possibility to publicly revoke a certificate before it expires (so setting default_crl_days equal to default days is not very sensible, you should just work without a CRL in such a case). Is this as simple as commenting out default_crl_days? I've noticed that a certificate with a longer default_days will be treated as expired when default_crl_days is reached. Yet, I don't see the CRL period in the signed certificate when I view it with the -text option. I'm afraid I don't understand the underlying CRL checking mechanism. Does the server (web, mail, etc.) check the CRL, or the client? No, you have to comment out crlDistributionPoints (and maybe some similar entries like nsCaRevocationUrl). If a crlDistributionPoint is coded into the certificate a verifying entity should download a new CRL every default_crl_days days, and if it is not possible to download the CRL (maybe because you forgot to publish the current version) the verification should fail! Otherwise an evil guy would swamp the CRL distribution point with DoS-attacks and could use a revoked cert till its expiry date. It's been mentioned elsewhere that the CRLs of major CAs can grow to be several MB, but I can't say that I've ever noticed such activity on either my servers or clients (not that I was looking for it, but I do actively monitor connections). As I see it CRLs are not often used, maybe just because of that reason. But from your description I'd guess that the size of the CRL should not be a problem in your environment. The disadvantage of a CRL is that it has to be accessible and kept up-to-date or the verification will fail. So using a CRL will require a stable net, stable webserver and someone (possibly a cron job or something like that) generating new CRLs in regular intervals. I can probably do that, although at the moment it would seem more manageable to push the CRL out to the small number of clients when necessary. On the other hand, it seems that simply replacing a certificate on the server is as effective as revoking it and publishing a CRL (assuming, of course, that noone has acquired the key/cert and is using it to masquerade as my server). In this case, a CRL would be most valuable in protecting the integrity of my root CA certificate (which could also be replaced and redistributed, I guess). OK, if someone acquired your CA's key you're deep in the dirt, regardless wether you use CRLs or not, since the evil one can build his/her own CRLs with the signature of your CA. ;) Wether you can do without a CRL is hard to say without knowing your detailed security requirements. If there are only few servers to distribute new certificates to, setting a shorter expiry date may do a similar job. On the other hand, if you are using the certificates for client access to important data you might like to be able to revoke a lost certificate within few days or even hours, in which case even a CRL might not be fast enough and you'd have to set up an OCSP server... Yes, I've glanced at OCSP, and it seems to be the most sensible approach. But is it widely supported? Is the OCSP server included with OpenSSL robust? Is it recommended to set up OCSP servers on port 80 to accommodate corporate firewalls? I have no current plans for issuing client certificates, but the need may arise in the future. I don't know very much about OCSP since I haven't used it till now. As I understand it it's a webserver-plugin (cgi or perl or something like that) that looks up a certificate's serial number in its local CRL and returns (essentially) TRUE or FALSE. [...] Ted ;) -- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 smime.p7s Description: S/MIME Cryptographic Signature
RE: d2i_RSAPublicKey doesn't work
If you're referring to http://www.openssl.org/support/faq.html
3. How do I read or write a DER encoded buffer using the ASN1 functions?
...
The opposite assumes we already have len bytes in buf:
unsigned char *p;
p = buf;
p7 = d2i_PKCS7(NULL, p, len);
At this point p7 contains a valid PKCS7 structure of NULL if an error
occurred. If an error occurred ERR_print_errors(bio) should give more
information.
The reason for the temporary variable 'p' is that the ASN1 functions
increment the passed pointer so it is ready to read or write the next
structure. This is often a cause of problems: without the temporary
variable the buffer pointer is changed to point just after the data that
has been read or written. This may well be uninitialized data and
attempts to free the buffer will have unpredictable results because it
no longer points to the same address.
--
I see where it says you need to create the temp var. So changed my code
to do that, but I still get a null ptr returned.
Code is now:
U8* tmp = buf;
RSA* pub = d2i_RSAPublicKey(0, (const U8**)tmp, *len);
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nils Larsch
Sent: Monday, July 18, 2005 1:10 PM
To: openssl-users@openssl.org
Subject: Re: d2i_RSAPublicKey doesn't work
Edward Chan wrote:
What am I doing wrong here? I generate an RSA key. Then I
DER encode
it. Then try to decode it, but the decode fails. The error says,
error:0D07207B:asn1 encoding
routines:ASN1_get_object:header too long
RSA* rsa = RSA_generate_key(2048, RSA_F4, 0, 0); if (rsa) {
if (RSA_check_key(rsa) 0)
{
int len = i2d_RSAPublicKey(rsa, 0);
U8* buf = new U8[len];
memset(buf, 0, len);
i2d_RSAPublicKey(rsa, buf);
// everything looks good up to here; I can see buf
gets filled with len number of bytes
// but then I try to get the public key
back by doing
the following, and it fails.
RSA* public_key = d2i_RSAPublicKey(0, (const
U8**)buf, len); // public_key is NULL; why???
if (!public_key)
{
char err[1024];
ERR_error_string(ERR_get_error(), err);
fprintf(stderr, Error : %s\n, err);
}
}
}
please read the FAQ
Nils
__
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: Investigating a leak
Doing this now, but since my app is a server, it never really reaches the end, and the leaks build up during its lifetime, which I'd rather hoped could be more than a day or so. As it is now, the process' virtual memory size quickly reaches 3.5 GB, and then malloc() starts failing. Something wrong is happening. Lots of folks are running apache/openssl servers for days, weeks, etc., at a time. If you're seeing memory leaks like you describe, then it is far more likely that the like is either in your code, or there's a bug in the way you're calling OpenSSL. Do you get the same growth when openssl isn't used? Make sure you xxx_free every object you xxx_new. /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
