Re: PEM vs. DER
On Thu, Mar 04, 1999, [EMAIL PROTECTED] wrote: If I wanted mod_ssl to use DER Base64 encoded certs by default, would it be as simple as doing a `perl -pi -e 's/PEM/DER/g;'` to the mod_ssl source files, and then adding '-outform DER' to makecrt.sh where appropriate? (compile and install afterwards of course) No, it isn´t such easy, because not all _PEM functions of OpenSSL have direct DER counterparts. But DER cert/key loading can be supported with a little bit of extra code, of course. But the question is: why do you want to use DER? The conversion via "openssl x509 ..." is trivial... So, what´s the reasons? Perhaps it´s actually interesting to support DER in mod_ssl in general? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: mod_ssl 2.2.4 (another FAQ? ;) )
On Fri, Mar 05, 1999, Steffen Dettmer wrote: I'm just preparing a test suite for upgrading our www servers to actual versions (from Apache/1.3.1 (Unix) mod_ssl/2.0.10 ;) ) This week I was very busy with hacking on mod_ssl. The result is now available: mod_ssl 2.2.4. Beside a lot of small changes at all edges for When it will be aviable at ".../mod_ssl/contrib/" (or where else)? Contrib? No, that's for user contributions. The official distribution from me is under distrib, of course. switching to OpenSSL 0.9.2 as the minimum required toolkit version we When it will be released? Is a pre-snapshot version for testing aviable? Maybe I should take a look, since I'll have some time... It's proposed for March 15th, 1999. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: mod_ssl 2.2.4 (another FAQ? ;) )
Contrib? No, that's for user contributions. The official distribution from me is under distrib, of course. Yes, I'm a camel ;) switching to OpenSSL 0.9.2 as the minimum required toolkit version we It's proposed for March 15th, 1999. Great. Currently I test with 0.9.1c (the compiler runs were all sucessful under Linux), on monday I'll compile under Irix useing native cc. (BTW: The 0.9.2 snapshot made a compiler error here, but I don't have time to check it today) Thanx, Steffen __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: mod_ssl 2.2.4 (another FAQ? ;) )
On Fri, Mar 05, 1999, Steffen Dettmer wrote: switching to OpenSSL 0.9.2 as the minimum required toolkit version we It's proposed for March 15th, 1999. Great. Currently I test with 0.9.1c (the compiler runs were all sucessful under Linux), on monday I'll compile under Irix useing native cc. (BTW: The 0.9.2 snapshot made a compiler error here, but I don't have time to check it today) Then at least send us the error message, please. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
mod_ssl 2.2.4 make failed
hello, I'm using Solaris 2.6 on Ultra1. I tried to compile the new mod_ssl-2.2.4-1.3.4 and get the following error when running make: cc -c -I/opt/apache/include -DSOLARIS2=260 -DMOD_SSL=202103 -DEAPI -KPIC -DSHARED_MODULE -I/opt/openssl-0.9.1c/include -DMOD_SSL_VERSION=\"2.2.4\" mod_ssl.c mv mod_ssl.o mod_ssl.lo "mod_ssl.c", line 203: too many struct/union initializers cc: acomp failed for mod_ssl.c *** Error code 2 make: Fatal error: Command failed for target `mod_ssl.lo' Current working directory /opt/mod_ssl-2.2.4-1.3.4/pkg.sslmod Any assistance is appreciated. thankyou -- Bill Stasiowski Office of Information Technology Atlanta, Georgia, 30332-0715 PHONE 404-894-7812 EMAIL: [EMAIL PROTECTED] __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PEM vs. DER
"Ralf S. Engelschall" [EMAIL PROTECTED] writes: On Thu, Mar 04, 1999, [EMAIL PROTECTED] wrote: If I wanted mod_ssl to use DER Base64 encoded certs by default, would it be as simple as doing a `perl -pi -e 's/PEM/DER/g;'` to the mod_ssl source files, and then adding '-outform DER' to makecrt.sh where appropriate? (compile and install afterwards of course) No, it isn´t such easy, because not all _PEM functions of OpenSSL have direct DER counterparts. But DER cert/key loading can be supported with a little bit of extra code, of course. But the question is: why do you want to use DER? The conversion via "openssl x509 ..." is trivial... So, what´s the reasons? Perhaps it´s actually interesting to support DER in mod_ssl in general? Because we, http://www.aventail.com/, are using Apache+mod_ssl+SSLeay in a "soon to be released" product. This new product will co-exist with our extranet server. This extranet server is ssl capable but uses some other ssl toolkit that only does DER Base64. Which means our existing cert management tools only do DER Base64. This is why I need mod_ssl to support DER Base64. My guess is that DER Base64 would be desirable whenever you'd like to have mod_ssl play nicely with anything from the commercial, proprietary, non-free world. -Tom __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PEM vs. DER
On Fri, Mar 05, 1999, [EMAIL PROTECTED] wrote: If I wanted mod_ssl to use DER Base64 encoded certs by default, would it be as simple as doing a `perl -pi -e 's/PEM/DER/g;'` to the mod_ssl source files, and then adding '-outform DER' to makecrt.sh where appropriate? (compile and install afterwards of course) No, it isn´t such easy, because not all _PEM functions of OpenSSL have direct DER counterparts. But DER cert/key loading can be supported with a little bit of extra code, of course. But the question is: why do you want to use DER? The conversion via "openssl x509 ..." is trivial... So, what´s the reasons? Perhaps it´s actually interesting to support DER in mod_ssl in general? Because we, http://www.aventail.com/, are using Apache+mod_ssl+SSLeay in a "soon to be released" product. This new product will co-exist with our extranet server. This extranet server is ssl capable but uses some other ssl toolkit that only does DER Base64. Which means our existing cert management tools only do DER Base64. This is why I need mod_ssl to support DER Base64. My guess is that DER Base64 would be desirable whenever you'd like to have mod_ssl play nicely with anything from the commercial, proprietary, non-free world. Ok, sounds like a reasonable suggestion. But do you want DER+Base64 or just plain DER? Because DER is a binary format while DER+Base64 is the binary plus Base64 transformed and PEM is actually DER+Base64+Header/Footer. So, what exactly do you understand under "DER Base64"? Do you want plain DER or really DER+Base64? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSLeay or openssl ?
On Fri, Mar 05, 1999, Fathi Ben Nasr wrote: What is the difference between SSLeay and openssl i.e. which one should I use (with mod-ssl 2.2.3-1.3.4 and apache) and why ? Although this should be asked on our openssl-users list, here is an answer: The difference are first a lot of bugfixes and new features and second: SSLeay is dead while OpenSSL is it's successor, so the question of difference is useless because OpenSSL isn't a competing product ;-) For details about the differences look at: http://www.openssl.org/news/changelog.html How can I generate certs for communicator 4.05 or ie4.x (export versions) ? My .crt files results to be invalid or corrupted to both clients. The .crt files of mod_ssl are server certificates. Although they can be used as client certificates you shouldn't use it for this, of course. The reason why it doesn't work for you is because they are in PEM format while for the browsers you usually need DER format or at least have to load via PKCS#12 or as DER with correct MIME types. Look inside the mod_ssl for a few hints about client certificates. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PEM vs. DER
On Fri, Mar 05, 1999, [EMAIL PROTECTED] wrote: "Ralf S. Engelschall" [EMAIL PROTECTED] writes: [snip] Ok, sounds like a reasonable suggestion. But do you want DER+Base64 or just plain DER? Because DER is a binary format while DER+Base64 is the binary plus Base64 transformed and PEM is actually DER+Base64+Header/Footer. So, what exactly do you understand under "DER Base64"? Do you want plain DER or really DER+Base64? I defer to our resident munitions expert, Marc VanHeyningen... blockquote We try to be liberal in what we accept, so we can read plain DER as well as DER+Base64 in many cases; for example, trusted roots can be specified in either, but if it's plain DER there isn't any good way to specify 1 root while DER+Base64 makes it easy to have multiple roots, look at them, cut and paste them, etc. Credentials files (socks5.certs and friends), simiarly, have to contain multiple objects (private key, certificate chain of 1 certificate) and so the easiest way to store those multiple objects with labels of which is what is by using base64 with BEGIN FOO- headers and footers. This also makes it easier to sanity check files by looking at them in text editors, reduces headaches with customers who occasionally have to email those files to support, etc. Obviously it makes the files slightly larger but that seems a small price to pay. Unless I'm misunderstanding him, I disagree with his assertion that PEM is "just" DER + base64 + header/footer; the headers/footers added by PEM are more complex than what we use, and what exactly goes in the DER is often a bit different, assuming he means the DER of the PKCS stuff rather than the PEM stuff. Our private key, for instance, is stored per PKCS#5/8, not per any PEM standard; certificates are raw X.509 DERs, base64-encoded with -BEGIN CERTIFICATE- thrown in front. /blockquote Ok, ok, when I understand you correctly, you want that mod_ssl can read any combination Let's see what I can do. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: ANNOUNCE: mod_ssl 2.2.4
Ralf S. Engelschall wrote: This week I was very busy with hacking on mod_ssl. The result is now available: mod_ssl 2.2.4. Beside a lot of small changes at all edges for preparing the final transition from SSLeay to OpenSSL this version fixes at I'am writing a CA SW based on apache-mod_ssl-1.3.4-2.2.0-2, SSLeay-0.9.0b-4, and mod-php3-3.0.7-1. I suppose to have to switch to OpenSSL too. Is it a difficult job; is OpenSSL syntax close to SSLeay command syntax? -- Mario __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: ANNOUNCE: mod_ssl 2.2.4
On Fri, Mar 05, 1999, Mario Fabiano wrote: Ralf S. Engelschall wrote: This week I was very busy with hacking on mod_ssl. The result is now available: mod_ssl 2.2.4. Beside a lot of small changes at all edges for preparing the final transition from SSLeay to OpenSSL this version fixes at I'am writing a CA SW based on apache-mod_ssl-1.3.4-2.2.0-2, SSLeay-0.9.0b-4, and mod-php3-3.0.7-1. I suppose to have to switch to OpenSSL too. Is it a difficult job; is OpenSSL syntax close to SSLeay command syntax? Exactly the same except that the command is named "openssl" instead of "ssleay" and that no shorthand symlinks are installed, i.e. instead of "x509" you've to write "openssl x509", etc. Anything else is backward compatible, of course. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PEM vs. DER
"Ralf S. Engelschall" [EMAIL PROTECTED] writes: [snip] Ok, ok, when I understand you correctly, you want that mod_ssl can read any combination Let's see what I can do. Much appreciated! Though I don't think every combination is required. At least not by us. DER Base64 encoding of PKCS#5/8 keys, and DER Base64 encoding of raw X.509 certs would be a nice start. -Tom __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PEM vs. DER
On Fri, Mar 05, 1999, [EMAIL PROTECTED] wrote:
"Ralf S. Engelschall" [EMAIL PROTECTED] writes:
[snip]
Ok, ok, when I understand you correctly, you want that mod_ssl can read any
combination Let's see what I can do.
Much appreciated! Though I don't think every combination is required. At
least not by us. DER Base64 encoding of PKCS#5/8 keys, and DER Base64
encoding of raw X.509 certs would be a nice start.
Ok, with the appended patch I was at least able to load PEM, DER+Base64 and
plain DER server.crt and server.key files. Please try it out with your
cert/keys and give me feedback, please.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
Index: ssl_engine_pphrase.c
===
RCS file: /e/apache/SSL/REPOS/mod_ssl/pkg.apache/src/modules/ssl/ssl_engine_pphrase.c,v
retrieving revision 1.28
diff -u -r1.28 ssl_engine_pphrase.c
--- ssl_engine_pphrase.c1999/03/04 09:25:47 1.28
+++ ssl_engine_pphrase.c1999/03/05 21:49:53
@@ -136,8 +136,7 @@
"Init: Can't open server certificate file %s", szPath);
ssl_die();
}
-pX509Cert = X509_new();
-if (!PEM_read_X509(fp, pX509Cert, NULL)) {
+if ((pX509Cert = SSL_read_X509(fp, NULL, NULL)) == NULL) {
ssl_log(s, SSL_LOG_ERROR|SSL_ADD_SSLERR,
"Init: Unable to read server certificate from file %s", szPath);
ssl_die();
@@ -194,7 +193,6 @@
myCtxVarSet(mc, 8, nPassPhraseDialogCur);
myCtxVarSet(mc, 9, bPassPhraseDialogOnce);
-pRSAKey = RSA_new();
nPassPhraseCur= 0;
nPassPhraseRetry = 0;
nPassPhraseDialogCur = 0;
@@ -212,8 +210,8 @@
ssl_die();
}
cpPassPhraseCur = NULL;
-bReadable = (PEM_read_RSAPrivateKey(fp, pRSAKey,
- ssl_pphrase_Handle_CB) ? TRUE : FALSE);
+bReadable = ((pRSAKey = SSL_read_RSAPrivateKey(fp, NULL,
+ ssl_pphrase_Handle_CB)) != NULL ? TRUE : FALSE);
ap_pfclose(p, fp);
/*
Index: ssl_util_ssl.c
===
RCS file: /e/apache/SSL/REPOS/mod_ssl/pkg.apache/src/modules/ssl/ssl_util_ssl.c,v
retrieving revision 1.3
diff -u -r1.3 ssl_util_ssl.c
--- ssl_util_ssl.c 1999/03/04 09:25:47 1.3
+++ ssl_util_ssl.c 1999/03/05 21:42:01
@@ -92,3 +92,85 @@
return;
}
+/* _
+**
+** High-Level Certificate / Private Key Loading
+** _
+*/
+
+X509 *SSL_read_X509(FILE *fp, X509 **x509, int (*cb)())
+{
+X509 *rc;
+BIO *bioS;
+BIO *bioF;
+
+/* 1. try PEM (= DER+Base64+headers) */
+rc = PEM_read_X509(fp, x509, cb);
+if (rc == NULL) {
+/* 2. try DER+Base64 */
+fseek(fp, 0L, SEEK_SET);
+if ((bioS = BIO_new(BIO_s_fd())) == NULL)
+return NULL;
+BIO_set_fd(bioS, fileno(fp), BIO_NOCLOSE);
+if ((bioF = BIO_new(BIO_f_base64())) == NULL)
+ return NULL;
+bioS = BIO_push(bioF, bioS);
+rc = d2i_X509_bio(bioS, NULL);
+BIO_free(bioF);
+BIO_free(bioS);
+if (rc == NULL) {
+/* 3. try plain DER */
+fseek(fp, 0L, SEEK_SET);
+if ((bioS = BIO_new(BIO_s_fd())) == NULL)
+return NULL;
+BIO_set_fd(bioS, fileno(fp), BIO_NOCLOSE);
+rc = d2i_X509_bio(bioS, NULL);
+BIO_free(bioS);
+}
+}
+if (rc != NULL x509 != NULL) {
+if (*x509 != NULL)
+X509_free(*x509);
+*x509 = rc;
+}
+return rc;
+}
+
+RSA *SSL_read_RSAPrivateKey(FILE *fp, RSA **rsa, int (*cb)())
+{
+RSA *rc;
+BIO *bioS;
+BIO *bioF;
+
+/* 1. try PEM (= DER+Base64+headers) */
+rc = PEM_read_RSAPrivateKey(fp, rsa, cb);
+if (rc == NULL) {
+/* 2. try DER+Base64 */
+fseek(fp, 0L, SEEK_SET);
+if ((bioS = BIO_new(BIO_s_fd())) == NULL)
+return NULL;
+BIO_set_fd(bioS, fileno(fp), BIO_NOCLOSE);
+if ((bioF = BIO_new(BIO_f_base64())) == NULL)
+ return NULL;
+bioS = BIO_push(bioF, bioS);
+rc = d2i_RSAPrivateKey_bio(bioS, NULL);
+BIO_free(bioF);
+BIO_free(bioS);
+if (rc == NULL) {
+/* 3. try plain DER */
+fseek(fp, 0L, SEEK_SET);
+if ((bioS = BIO_new(BIO_s_fd())) == NULL)
+return NULL;
+BIO_set_fd(bioS, fileno(fp), BIO_NOCLOSE);
+rc = d2i_RSAPrivateKey_bio(bioS, NULL);
+BIO_free(bioS);
+}
+}
+if (rc != NULL rsa != NULL) {
+if (*rsa != NULL)
+
Re: Client Certificate bits and mod_perl
On Fri, Mar 05, 1999, Alfredo Raul Pena wrote: I'm sorry about the insistence, but what do anyone thinks about this? Regards, Alfredo Since mod_ssl 2.1 you can get _all_ ingredients of a certificate via environment variables SSL_. What ingredients are you missing? I think the problem is that I'm not using mod_perl for CGI scripts (where you have the info via the environment) but from a AuthHandler... From there I tried accessing subprocess_env without success, none of the SSL_ veriables are there. mod_ssl _does_ set the vars in the subprocess_env table, but it does it in the Fixup handler which comes _after_ the auth handler. As a workaround you can try to do your jobs inside another Fixup handler. Hmmm.. I'm not sure whether I should move the stuff in mod_ssl from Fixup to Auth. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
