CGI over SSL

[Willem Grooters]

Two non-related nodes, OpenVMS 7.3-2, SWS 2.1-1


Situation: Page accessed over https contains link leading to CGI-procedure (same server, same port).
Configuration equal on both systems, except for certificatefile and mapping.

On both systems, the page is shown correctly, but on one system, the link shows the right result; on the other system, the link results in "Page not found", but the file does exist and protection should not constitute a problem:

(IDENTIFIER=[AP_HTTPD,APACHE$WWW],ACCESS=READ+WRITE+EXECUTE)
(IDENTIFIER=APPL_USER,ACCESS=READ+EXECUTE)

(The second identifier is granted to APACHE$WWW)

[Jeremy Begg]

You said, "Configuration equal on both systems, except for certificatefile and mapping."

I'm no Apache expert (give me WASD any day) but if the mappings are not identical could that be the problem?

Does VMS log any security audit alarms when you try to access the "missing" page?

Regards,
Jeremy Begg

[Willem Grooters]

Ideally, there would be no difference but we use different named concealed devices than the target system. Ideally, there would be no difference, but reality is never ideal:

Source: APPL_SUB_CGI ==> APPL_ROOTY:[SUB.CGI]
Target: APPL_SUB_CGI ==> ANOTHERROOT:[SUB.CGI]

That is: the name used in the URL maps are equal but the mapping is different. But as long as these logicals are referring to the right location (they do) and are defined when APACHE starts (/SYSTEM - they do) this should not be a problem.
And it isn't; static pages are aside the CGI directory (root:[SUB.HTML]) and can be accessed.

Logs (ACC, Audit) show nothing, The apache access log just that the result of the URL of HTML pages is 200, but accessing a CGI procedure (any, in fact) is 404, and that's the problem to solve...

"give me WASD any day": Count me in. If I were in a position to change webserver over here, I would. I wouldn't have this problem anyway - and I wouldn't need ITRC to solve it.

[Willem Grooters]

One more thing: It did work before, without SSL. But since secure access is a requirement, the configuration was changed but only in that aspect.

[Willem Grooters]

More information:

We found that mapping using a logical that contains a "$" seems to be part of the problem:

ScriptAlias /APPL-sub-cgi/ "appl$sub:[cgi]"

results in a " Page not found" error (404).

Now this has been changed to

ScriptAlias /APPL-sub-cgi/ "appl_sub:[cgi]"

after this logical was added to LNM$SYSTEM.
Restarted CSWS, of course.

Next, we get "Internal server error" and ERROR_LOG shows:

File does not exist: /apache$root/htdocs/APPL-sub-cgi

That is correct: that file doesn't exist.
It seems mapping is simply not done!

However, the logical appl$sub_root is used in Documentroot, ErrorLog and Customlog, and that does NOT cause problems.

It seems mapping is simply not done.

[Willem Grooters]

Solved.

Multiple issues in the configuration of this virtual host caused the problems:

* failure finding the files (both CGI-procedure and static page) was cause by the naming of the logicals:

ScriptAlias /appl_sub/ "/appl_sub/cgi"

is fine with, or without SSL, but

ScriptAlias /appl_sub/ "/appl$sub/cgi"

causes "page not found" (code 404) when SSL is enabled.

* An error in the configuration was completely overlooked. The original file contains the right line:

AddHandler cgi-script .cgi .com .exe

but the failing configuration contained:

AddHandler .cgi .com .exe

However, without SSL, the script was executed; with SSL, this error caused start of download - and failre because "CGI" was not found; if the URL contained the full name ("CGI.COM") there would not be a problem.

When we chnaged the logicals of DocumentRoot and the mapping rules and removed "$" - and deassignd the logicals - the server did not start. This was an easy guess: the removed logicals were still used in the definition of the logfiles... But IMHO, SWS should have signalled an error or warning; even more: should run and serve hosts that were properly defined...

[Willem Grooters]

The difference in behaviour is now somewhat documented :)