[an error occurred while processing the directive]
![]() |
cosign-discuss at umich.edu |
general discussion of cosign development and deployment | |
Fair enough. If I restrict my HTTP queries to using https I don't get any remarkable error numbers. In fact, things seem to be working relatively smoothly. helloCosign is reaffirming my identity (isn't that always nice? :))
Thanks. I guess that cosign protected services need to simply reject non-ssl queries to avoid this most unhelpful error.
On Wed, Mar 17, 2004 at 06:11:49PM -0500, kevin mcgowan wrote:This line:
134.10.7.24 - - [17/Mar/2004:14:30:21 -0800] "\x80g\x01\x03" 200 4779
suggests maybe a client is trying to talk https on a non-encrypted port. and the line before it says:
https://weblogin.reed.edu:80/test/test.html
which suggests the same thing. Are you trying to host a cosign service
over http? This is definitely something we've talked about enabling,
but it is precluded by default (since the cookie would be replayable
and easily sniffed).
One other thing is that the CosignService setting:
CosignService cosign-reed
doesn't need to include the "cosign-" since we'll append that. This
will prevent service names like 'cosign-cosign-reed.' This won't cause
any problems, of course, but it is worth knowing, I think.
Kevin
On Mar 17, 2004, at 5:45 PM, Sam Noble wrote:
Hopefully my problem is obvious, but I seem to have run into a wall configuring cosign for my site.
I don't know if this -12281 error is a Mozilla error code, something apache understands, or something specific to cosign. Certainly IE doesn't bother giving me an error code at all (in fact, I get the error page that looks like DNS problems from IE). Mozilla (well, firefox) reports that "weblogin.reed.edu has sent an incorrect or unexpect message" and then presents me with this error code.
As best I can tell, I've followed the cosign installation instructions.
I tried running cosignd in debug mode: debug: STARTTLS debug: REGISTER cosign=IBWtm41+KEAFH1hXrKlxBliHoUI8MpDZt6+30ZD+UnwSho8X9yjsTp5- RAVZhtZ+hGDDWPsSwAtNh5iGYa34BndCV+3Fx54WImgoNcRnbo477vYoLQli1hhqGF8K 134.10.7.24 cosign-cosign- reed=plgKDvatwIBF4maF38AkvzDmxrc5+mB2bldYmlWmJnJbAeabwTxvh9u14y- oc4dDURM2GA59UbZQTo+VCy7jyuo43ZHnh99Z9BVitpTJ5aV+ZnLLkPW-4S6W34Mm
Something similar is shown on stdout whenever I try to access a cosign
protected page (and I get this -12281 error as well).
My apache 2 access_log looks like the following:
134.10.7.24 - - [17/Mar/2004:14:30:20 -0800] "GET /test/test.html
HTTP/1.1" 302 403
134.10.7.24 - - [17/Mar/2004:14:30:20 -0800] "GET
/?cosign-cosign-reed=36J+O2jiQ2s0v8WTi6o1GgZPFlTTQukO-
sb8UjiE2aK7t50Kt6gWVrrrZqSi9W22+W9Sp4fSiYESEkV9NjHJPjonT394hbIzHlwaPQ G+
-9WN41jL7Nd2k2O-b3PF;&https://weblogin.reed.edu:80/test/test.html
HTTP/1.1" 302 227
134.10.7.24 - - [17/Mar/2004:14:30:21 -0800] "\x80g\x01\x03" 200 4779
The error log doesn't seem to say a whole lot -- although once in a while I see: [Wed Mar 17 14:27:37 2004] [error] [client 134.10.7.24] net_check: 3: 534 CHECK: Who me? Dunno.
These errors don't typically correspond to the major error I receive whenever I try to look at a cosign protected page.
strace'ing the cosign daemon doesn't reveal any smoking guns.
I use the following in my httpd.conf:
CosignProtected On CosignHostname weblogin.reed.edu CosignRedirect https://weblogin.reed.edu/ CosignPostErrorRedirect https://weblogin.reed.edu/post_error.html CosignCrypto /var/cosign/certs/key.pem /var/cosign/certs/cert.pem /var/cosign/certs/CA CosignService cosign-reed
And my (self-signed) ssl certs check out okay.
Is there anything else I can/should take a look at to diagnose my problem?
... "In, as you say, the mud." ...
!DSPAM:4058f7a739952909813147!