Re: Server refusing connections
Ralf S. Engelschall wrote: No, when the above two commands didn't complain the server.crt and server.key are at least in correct format. Then, as you already mentioned yourself in another reply, you should check the file permissions. Perhaps the files are not readable for the user who starts Apache? OTOH they are read at startup time, and your error occurs when the key is configured under run-time. So file permissions shouldn't be your problem. H It's fine, I tracked things down. The wrong key file had been copied over to the production server, so it didn't match the crt. Thanks for the advice in any case! -- James H.G. Redekop | [EMAIL PROTECTED] Web Programmer | http://www.residents.com/ The Residents UUNET Canada | http://www.residents.com/Goons/The Goon Show [EMAIL PROTECTED] | http://www.residents.com/Tzoq/ Home Page __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Suggestion
On Wed, Jan 20, 1999, Magnus Stenman wrote:
It would be nice if httpd would check
its name when starting up -- if its
httpsd, define SSL, otherwise don't
Then you only have to create a
symlink to httpd named httpsd
to choose which type of server to run
instead of the "ugly" -DSSL
The problem is that now with Apache 1.3.4 a simple --target=foobar is all you
need to name it "foobar". And so "httpsd" is just a historical example of a
name. A lot of people will use "apache", so where to start and where to end
with this? OTOH renaming a file is not far away from creating a simple wrapper
script named "httpsd" which runs "httpd -DSSL". And the second argument is:
The -DSSL is just the way the _default_ configuration handles the stuff to let
you startup Apache with and without SSL. When you rename it to httpsd you
usually always want to run it with SSL, so why do you not just remove the two
IfDefine's? For instance my real world server configurations never have
IfDefine SSL, it's just a convenient way to provide both and this way is the
reasonable way for the default config. But no one forces you to use the
default config ;-)
But when you really want this feature, here is a possible patch
which does the trick for you:
Index: http_main.c
===
RCS file: /e/apache/SSL/REPOS/mod_ssl/pkg.apache/src/main/http_main.c,v
retrieving revision 1.17
diff -u -r1.17 http_main.c
--- http_main.c 1999/01/10 11:07:23 1.17
+++ http_main.c 1999/01/20 14:06:45
@@ -4551,6 +4551,11 @@
ap_setup_prelinked_modules();
+#ifdef EAPI
+if (strcmp(ap_server_argv0, "httpsd") == 0)
+ap_add_config_define("SSL");
+#endif
+
#ifndef TPF
while ((c = getopt(argc, argv,
"D:C:c:Xd:f:vVlLR:Sth"
Although I personally don't want to commit it to the mod_ssl source
tree, because I think it's a too specialized thing.
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: [BugDB] Compilation error (PR#85)
On Wed, Jan 20, 1999, [EMAIL PROTECTED] wrote:
Full_Name:
Version: 2.1.7-1.3.4
OS: AIX 4.2 / apache 1.3.4
Submission from: felix.adpcl.com (194.98.137.100)
Error when compiling src/modules/ssl/mod_ssl.c
"ssl_expr.h", line 103.51: 1506-046 (S) Syntax error.
Yes, that's because of a not-allowed trailing comma in this header file which
GCC doesn't complain about (so I never recognized it) but strict ANSI C don't
permits. It's already fixed for mod_ssl 2.1.8. In the meantime you can apply
the following patch:
Index: ssl_expr.h
===
RCS file: /e/apache/SSL/REPOS/mod_ssl/pkg.apache/src/modules/ssl/ssl_expr.h,v
retrieving revision 1.8
diff -u -r1.8 ssl_expr.h
--- ssl_expr.h 1999/01/02 16:46:16 1.8
+++ ssl_expr.h 1999/01/20 14:11:36
@@ -100,7 +100,7 @@
op_NOP, op_ListElement,
op_True, op_False, op_Not, op_Or, op_And, op_Comp,
op_EQ, op_NE, op_LT, op_LE, op_GT, op_GE, op_IN, op_REG, op_NRE,
-op_Digit, op_String, op_Regex, op_Var, op_Func,
+op_Digit, op_String, op_Regex, op_Var, op_Func
} ssl_expr_node_op;
typedef struct {
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: [BugDB] Compilation error (PR#86)
On Wed, Jan 20, 1999, [EMAIL PROTECTED] wrote:
Full_Name:
Version: 2.1.7-1.3.4
OS: AIX 4.2 / apache 1.3.4
Submission from: felix.adpcl.com (194.98.137.100)
Error when compiling ca-fix.c
example:
make certificate TYPE=test
+ finding random files on your platform
+ building ca-fix auxiliary tool
xlc ..
"ca-fix.c", line 450.24 (E) Operation between types "unsigned char *" and "char
*" is not allowed
"ca-fix.c", line 459.24 (E) Operation between types "unsigned char *" and "char
*" is not allowed
"ca-fix.c", line 462.49 (E) Function argument assignment between types "const
char *" and "unsigned char *" is not allowed
"ca-fix.c", line 475.42 (E) Function argument assignment between types "char *"
and "unsigned char *" is not allowed
"ca-fix.c", line 512.45 (E) Function argument assignment between types "unsigned
char *" and "char *" is not allowed
"ca-fix.c", line 588.6 (S) Redeclaration of add_ext differs from previous
declaration on line 76 of "ca-fix.c"
"ca-fix.c", line 588.6 (I) Prototype for function add_ext must contain only
promoted types if prototype and nonprototype declarations are mixed
"ca-fix.c", line 588.6 (I) Parameter 3 has type "char" which promotes to "int"
Oh hell, AIX 4.2 But nevertheless this nasty C compiler is right. There
are type inconsistencies inside ca-fix.c. But the last tree messages are just
too sensible ones. I've fixed all of them and tried it under AIX 4.2 myself
and now it silently compiles ca-fix without complains. It's fixed in mod_ssl
2.1.8. In the meantime I append you the patch I've committed to for 2.1.8.
Thanks for the feedback.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
Index: ca-fix.c
===
RCS file: /e/apache/SSL/REPOS/mod_ssl/pkg.apache/src/support/ca-fix.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ca-fix.c1998/10/09 10:31:12 1.1
+++ ca-fix.c1999/01/20 14:57:06 1.2
@@ -41,12 +41,10 @@
ASN1_INTEGER *pathlen;
} BASIC_CONSTRAINTS;
-int i2d_BASIC_CONSTRAINTS(BASIC_CONSTRAINTS * a, unsigned char **pp);
-ASN1_OBJECT *__OBJ_txt2obj(char *name);
+int i2d_BASIC_CONSTRAINTS(BASIC_CONSTRAINTS *, unsigned char **);
+ASN1_OBJECT *__OBJ_txt2obj(char *);
-int i2d_BASIC_CONSTRAINTS(a, pp)
- BASIC_CONSTRAINTS *a;
- unsigned char **pp;
+int i2d_BASIC_CONSTRAINTS(BASIC_CONSTRAINTS *a, unsigned char **pp)
{
M_ASN1_I2D_vars(a);
if (a-ca)
@@ -54,7 +52,6 @@
M_ASN1_I2D_len(a-pathlen, i2d_ASN1_INTEGER);
M_ASN1_I2D_seq_total();
-
if (a-ca)
M_ASN1_I2D_put(a-ca, i2d_ASN1_BOOLEAN);
M_ASN1_I2D_put(a-pathlen, i2d_ASN1_INTEGER);
@@ -73,13 +70,11 @@
STACK *exts;
STACK *extusage;
-void add_ext(char *name, char *val, char crit);
+void add_ext(char *, char *, char);
unsigned char extbuf[10240];
-int main(argc, argv)
- int argc;
- char **argv;
+int main(int argc, char **argv)
{
char *infile = NULL, *outfile = NULL, *keyname = NULL;
BIO *in = NULL, *out = NULL, *inkey = NULL, *bio_err = NULL;
@@ -93,8 +88,7 @@
unsigned char setkey = 0;
X509 *cert;
EVP_PKEY *pkey = NULL;
-BASIC_CONSTRAINTS bcons =
-{0, NULL};
+BASIC_CONSTRAINTS bcons = {0, NULL};
EVP_MD *dgst;
if (bio_err == NULL)
@@ -447,7 +441,7 @@
fprintf(stderr, "Invalid raw extension length\n");
exit(1);
}
-for (p = tmpext-value; *p; p++)
+for (p = (unsigned char *)tmpext-value; *p; p++)
if (!isxdigit(*p)) {
fprintf(stderr, "Extension %s invalid hex digit %c\n",
tmpext-value, *p);
@@ -456,10 +450,10 @@
rawlen = 1;
rawext = Malloc(rawlen);
tmphex[2] = 0;
-for (p = tmpext-value, q = rawext; *p; p += 2, q++) {
+for (p = (unsigned char *)tmpext-value, q = rawext; *p; p += 2, q++)
+{
tmphex[0] = p[0];
tmphex[1] = p[1];
-*q = (unsigned char) strtol(tmphex, NULL, 16);
+*q = (unsigned char)strtol((const char *)tmphex, NULL, 16);
}
str = ASN1_OCTET_STRING_new();
ASN1_OCTET_STRING_set(str, rawext, rawlen);
@@ -472,7 +466,7 @@
BIO_printf(bio_err, "Error opening file %s\n", tmpext-value);
ERR_print_errors(bio_err);
}
-extlen = BIO_read(tmpin, extbuf, sizeof(extbuf));
+extlen = BIO_read(tmpin, (char *)extbuf, sizeof(extbuf));
str = ASN1_STRING_new();
ASN1_OCTET_STRING_set(str, extbuf, extlen);
}
@@ -509,7 +503,8 @@
Re: Server refusing connections
Ralf S. Engelschall wrote: It's fine, I tracked things down. The wrong key file had been copied over to the production server, so it didn't match the crt. Thanks for the advice in any case! Oh, that's good news ;-) Then it was just some sort of a configuration error... Yes -- painful to track down but easy to solve once found. ~ James H.G. Redekop | [EMAIL PROTECTED] Web Programmer | http://www.residents.com/ The Residents UUNET, MCI WorldCom| http://www.residents.com/Goons/The Goon Show [EMAIL PROTECTED] | http://www.residents.com/Tzoq/ Home Page __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[BugDB] mod_ssl 2.1.7 doesn't work on Digital Unix (PR#83)
Full_Name: Andrew J Cosgriff Version: 2.1.7 OS: Digital Unix 4.0D Submission from: proxy.monash.edu.au (130.194.11.7) Upgrading from apache 1.2.6+ben'ssl to 1.3.4 + mod_ssl 2.1.7 has caused me a fair bit of grief - everything seems fine (i'd done the upgrade on Solaris boxes with no problems) but as soon as i try and connect to the https port through my browser, I get : httpd: [Wed Jan 20 15:32:58 1999] [error] [client 130.194.2.70] Invalid method in request @ httpd: [Wed Jan 20 15:36:17 1999] [error] [client 130.194.2.70] Invalid method in request k I went back and got mod_ssl 2.0.15 (and apache 1.3.3) and it all seems to work ok. But it seems something's up with 2.1.x that stops it working on Digital Unix somehow ? I'm using SSLeay 0.9.0b too. __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Questions about mod_ssl with ie
On Tue, Jan 19, 1999, Shane Wegner wrote: I have setup mod_ssl with Apache 1.3.4 on my web server according to the instructions in the INSTALL file. I used a self-signed key with "make certificate TYPE=custom" and it worked in lynx without a problem. Tests in s_client showed a 1024 bit key. I then fired up the win95 machine and tried to access the site using IE4 and it said it couldn't access it because the key was signed by an unknown CA. This is understandable but when I went to view certificate, the quality said "40 bit - Low" which indicates that the key is low grade. Strange since s_client said 1024 bit. Furthermore, IE had no way to override the unknown CA problem so I couldn't connect at all. The "40 bit" display usually means the grade of the connection and not really the key. The key is 1024, but I guess you're using an export-version of IE you get only a EXP-X cipher on SSL handshake. Just look inside the mod_ssl logfile, there the cipher is displayed. What I am wonder is 1) Is that an IE bug or a SSLEAY bug with the seemingly different bitrates? Neither of them. The 40bit quality is caused by the export restrictions built into your IE, I think. The fact that it doesn't know your CA is another problem. I've no experiences with IE under Win95, so I cannot help you in getting our CA cert recognized by it. 2) Can IE load an https site even if it is signed by an unknown (to it) CA? Sorry if the last question is offtopic for this list but I couldn't find anything in the manual or FAQ. I think, IE will not accept connections until you've loaded your CA cert into IE for correct verification of the server cert. 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: [BugDB] mod_ssl 2.1.7 doesn't work on Digital Unix (PR#83)
On Wed, Jan 20, 1999, [EMAIL PROTECTED] wrote: [...] Upgrading from apache 1.2.6+ben'ssl to 1.3.4 + mod_ssl 2.1.7 has caused me a fair bit of grief - everything seems fine (i'd done the upgrade on Solaris boxes with no problems) but as soon as i try and connect to the https port through my browser, I get : httpd: [Wed Jan 20 15:32:58 1999] [error] [client 130.194.2.70] Invalid method in request @ httpd: [Wed Jan 20 15:36:17 1999] [error] [client 130.194.2.70] Invalid method in request k I went back and got mod_ssl 2.0.15 (and apache 1.3.3) and it all seems to work ok. But it seems something's up with 2.1.x that stops it working on Digital Unix somehow ? I'm using SSLeay 0.9.0b too. Sounds like your HTTP connect reaches a non-SSL-enabled port on your server. Make sure the "SSLEngine on" is in place and that the VirtualHost really matches the Listen directives and your IP addresses. 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]
Questions about mod_ssl with ie
Hi, I have setup mod_ssl with Apache 1.3.4 on my web server according to the instructions in the INSTALL file. I used a self-signed key with "make certificate TYPE=custom" and it worked in lynx without a problem. Tests in s_client showed a 1024 bit key. I then fired up the win95 machine and tried to access the site using IE4 and it said it couldn't access it because the key was signed by an unknown CA. This is understandable but when I went to view certificate, the quality said "40 bit - Low" which indicates that the key is low grade. Strange since s_client said 1024 bit. Furthermore, IE had no way to override the unknown CA problem so I couldn't connect at all. What I am wonder is 1) Is that an IE bug or a SSLEAY bug with the seemingly different bitrates? 2) Can IE load an https site even if it is signed by an unknown (to it) CA? Sorry if the last question is offtopic for this list but I couldn't find anything in the manual or FAQ. Thanks in advance, Sahen -- Shane Wegner: [EMAIL PROTECTED] Tel: (604) 930-0530 Sysadmin, Continuum Systems: http://www.cm.nu Personal website: http://www.cm.nu/~shane Celine Dion Fan site: http://www.celine.nu/ PGP key: http://www.cm.nu/~shane/pgp.txt ICQ UIN: 15706546 PGP signature
Re: Server refusing connections
On Tue, Jan 19, 1999, James H.G. Redekop wrote: [...] Usually it doesn't matter where it was generated, because the format and encoding is standardized. What you should do is to run the commands $ ssleay x509 -noout -text -in server.crt $ ssleay rsa -noout -text -in server.key and make sure that both print reasonable things and don't complain. They *seem* sane enough -- no complaints, no errors, lots of two-digit binary numbers seperated by colons (in case you hadn't guessed, I'm not particularily encryption-literate...) I guess you're problem is already at this stage. Perhaps the server.key is not PEM encoded, etc. How could I tell, or should the above have told me? Is there a way of getting more detailed logging? No, when the above two commands didn't complain the server.crt and server.key are at least in correct format. Then, as you already mentioned yourself in another reply, you should check the file permissions. Perhaps the files are not readable for the user who starts Apache? OTOH they are read at startup time, and your error occurs when the key is configured under run-time. So file permissions shouldn't be your problem. H 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: [BugDB] Server refusing connections (PR#84)
On Tue, Jan 19, 1999, James H.G. Redekop wrote: [...] Usually it doesn't matter where it was generated, because the format and encoding is standardized. What you should do is to run the commands $ ssleay x509 -noout -text -in server.crt $ ssleay rsa -noout -text -in server.key and make sure that both print reasonable things and don't complain. They *seem* sane enough -- no complaints, no errors, lots of two-digit binary numbers seperated by colons (in case you hadn't guessed, I'm not particularily encryption-literate...) I guess you're problem is already at this stage. Perhaps the server.key is not PEM encoded, etc. How could I tell, or should the above have told me? Is there a way of getting more detailed logging? No, when the above two commands didn't complain the server.crt and server.key are at least in correct format. Then, as you already mentioned yourself in another reply, you should check the file permissions. Perhaps the files are not readable for the user who starts Apache? OTOH they are read at startup time, and your error occurs when the key is configured under run-time. So file permissions shouldn't be your problem. H 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] __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
