OpenVMS Notes: WASD HTTPd (and the y2k20 dilemma)

Edit: 2020-04-13 (this is a work in progress)

2k20 - a potential crisis in 2020

Modern browsers in 2020 will expect to "connect HTTPS" only using TLSv1.2 and TLSv1.3 (this assumes that support for everything from SSLv3 to TLSv1.1 will be removed)

While browsers are constantly being updated because of their financial use in everything from on-line purchases to on-line investing and banking, many web servers are not. What is worse it this: many organizations, including governments large and small, are slow to update software

comment: Firefox has been warning for several months (today is 2019-08-25) that one of my servers is preferentially offering connections via TLS-1.0 (the lock icon is closed but is orange). Chrome and IE11 each present a green lock icon.

The OpenVMS ecosystem

  • Two companies are currently supporting OpenVMS (but this is about to change)
    • In 2014, HP transferred the rights to develop/support OpenVMS to VSI (VMS Software Inc)
    • In 2015, HP split into two companies: HP (most desktop products) and HPE (enterprise)
    • HPE continued to support OpenVMS software contracts sold to HP customers before 2015 (they also sold/supported VSI products)
    • Early in 2019, HPE removed most OpenVMS stuff (documentation as well as software) from their website including CSWS-2.2-1 (Compaq Secure Web Services) based upon Apache 2.0.63
    • If you have an OpenVMS support contract with HPE, then you will be able to request the latest version of file MOD_SSL (an Apache module for CSWS) which is based upon OpenSSL-1.0L but does not implement TLSv1.3
      • HPE has announced the end of all OpenVMS support by the end of 2020.
    • Businesses requiring CSWS/Apache on OpenVMS should immediately move their support contracts over to VSI where you will have access to a new version of CSWS based upon Apache 2.4.12
      • caveat: you may be required to update your OS to OpenVMS-8.4-2 so do not wait until the last minute
  • For companies and/or hobbyists financially unable to move to VMS Software Inc., your the only remaining option is to replace CSWS/Apache with WASD HTTPd (the high quality web server from down-under) which is not based upon Apache.
    • WASD already supports TLSv1.2 and TLSv1.3
    • "I think" support agreements may be available
  • This web-page will document my efforts to replace CSWS/Apache with WASD HTTPd on a sacrificial laboratory system (we employ a lot of CGI including one SOAP-based feed)
  • Web server products available for VMS/OpenVMS
    Publisher Product Name Apache
    VAX Alpha Itanium x86-64 Active Notes
    Compaq/HP/HPE CSWS (1) 2.0.xx N Y Y N ? HPE will exit the OpenVMS business in 2020
    Old CSWS (products, patches, plugins) were free up until 2016
    Since then only patches are available if you have an HPE support agreement
    VSI CSWS (2) 2.4 N Y Y Y Y New CSWS (available with new support agreement)
    Ohio State University OSU DECthreads n/a Y Y N N N Product hasn't been supported for more than a decade
    Can be found on the VMS Freeware packages
    VSM Software Services WASD HTTPd n/a Y Y Y Y Y Still actively supported

Introduction to WASD HTTPd

  • WASD HTTPd - is a very high quality free web server from VSM Software Services in Australia
    • it runs on all VMS and OpenVMS platforms: VAX, Alpha, and Itanium
    • it will run on x86-64 when VSI finally publishes a OpenVMS-9 for that CPU architecture
    • it is NOT based upon Apache
    • it is published with all the source code so if you can program in C then you can improve/extend/tinker
    • it can link to its own SSL libraries which already support TLS-1.3, or HP-SSL (based upon OpenSSL-0.9 and lower), or HP-SSL1 (OpenSSL-1.0 and higher)
    • excerpt from page-13 of the book OpenVMS with Apache, OSU, and WASD
      The idea with WASD was to be a really good VMS-only server: Mark Daniel says, "I suffered a bit of a VMS cringe when amongst my UNIX colleagues (VMS was perceived to be a bit slow and cumbersome), so I have also endeavored to make WASD as fast and efficient as I could, avoiding C run-time library and even RMS code layers where it was feasible and worth it. I also wanted a similarly tight scripting environment and have spent a lot of time honing this aspect"
    • Trivia: WASD = "Wide Area Surveillance Division". WASD was previously known as HFRD (High Frequency Radar Division) of Australia's Defense, Science and Technology Organization
Executive Summary:
  • What an unexpected surprise. WASD HTTPd is the fastest web server I have worked on to date.
    I am currently supporting web servers on these production platforms...
    Hardware CPU Cores Memory Network OS Software
    rx2800-i2 Itanium2 8 64G IPv4 on 1Gb/s OpenVMS-8.4 CSWS/Apache 2.0.xx
    DL385p-gen8 AMD x86-64 24 132G IPv4 on 1Gb/s CentOS-7.5 Apache 2.4.xx
    rx2660 Itanium2 8 16G Ipv4 on 1Gb/s OpenVMS-8.4 WASD HTTPd 11
    ...and it appears that WASD on the oldest hardware is able to out-perform Apache on the newest hardware (caveat: I haven't done any full-load stress tests just yet)
  • WASD HTTPd is published with all the source code. This means that if Adelaide gets hit with an asteroid you will be able to fix your own code (provided you have access to the DECC "C compiler)
  • The source code is mirrored in at least three other locations (see asteroid comment)

First Steps

  • download all the zip files you think you will need from here: (or the various mirror sites)
    • caveat: do not skip any CUP (cumulative update package) files. I wasted a whole day trying to get both Server Admin and SYSUAF to work (I assumed I was doing something wrong). I was only successful after I noticed, then installed, the CUP file (probably need new eyeglasses)
  • none of these files offer executables so you will need to download a vanilla package (necessary to "compile-link" or just "link") as well as the architecture-specific files

Unzip then install


$! DCL script to unzip WASD
$! this is an rx2660 (Itanium2)
$! CSWS/Apache is located on disk dka200 so that's where I'll put WASD
$ define/job yada CSMIS$USER3:[ADMCSM.NEIL._WASD]	! files where downloaded here
$ set default DKA200:[000000]				! move to root of disk dka200
$ unzip				! also creates folder [WASD_ROOT}
$ unzip				!
$ set default [WASD_ROOT]				!
$ unzip yada:WASD_CUP_1130b.ZIP 			! do not forget this (or SYSUAF stuff won't work)
$ unzip			! optional

Install (part 1) you need a DEC-C compiler to do perform step 1 so consider starting with step 2

$set default wasd_root:[000000]				!
$@install						!


Package executables must be built.

0. skip this step 
1. compiling from source, then linking 
2. linking (separate package) object modules 

Select build method [0]:


Install (part 2) really cool because you have a choice


A supported Secure Sockets Layer (SSL) toolkit has been detected.
Those with item numbers are available for building, 'x's are not available.

0. do not build an SSL version 
1. OpenSSL (prior to v1.1.0) toolkit
x. OpenSSL (v1.1.0 or later) toolkit 
2. OpenVMS SSL1 product (HP)                    (OpenSSL 1.0 and higher)
x. WASD OpenSSL package                         ("x" because download it) 
x. OpenVMS SSL product (HP) no longer supported (OpenSSL 0.9 and lower)

Select item number [2]:

Config then initial start

  • now read install-and-config as well as features (or download the PDFs of those html docs from here)
    • the vanilla http server (port 80) installs itself.
    • The secure https server (443) will not work without having chapter-4 of features open while you edit the config files documented in install-and-config. IMHO, this is a good thing since we've all worked on systems initially set up by "the brain dead". Security is no laughing matter. I was not able to get HTTPS working without first using the OpenSSL CLI from another system
  • quick steps 1
    • locate your current ssl certificate file (name.crt) and key file (name.key)
    • copy both of these files into a third file with an extension of ".pem" (name.pem)
  • quick steps 2:
    • edit this file: [WASD_ROOT.local]wasd_config_global.conf
      field current contents new contents notes
      [SecureSocket] disabled enabled  
      [SSLversion] TLSvALL TLSvALL,SSLv3 my system will require SSLv3 for a time
      [SSLcipherList]   MEDIUM:HIGH https will not work if this field is BLANK
      [SSLcert]   dka100:[certificates]name.pem https will not work if this field is BLANK
      [SSLkey]     leave this field BLANK
      [SSLverifyPeerCAFile]   dka100:[certificates]vendor.crt this is the vendor's chain file (in PEM format)
      this is standard
      this is the name of our Apache home page
      [Http2Protocol] enable disable disable for use with Firefox and Chrome in 2019
  • quick step 3:
  • https testing
    • testing with browsers can be problematic because they all implement different levels of security. So I recommend you first test with the OpenSSL CLI. Do not move to browsers until this command works
      $ openssl s_client -connect www.server.ext:443 -showcerts
    • This is an example of a failure (handshake could not find, or agree upon, a common protocol):
      $ openssl s_client -connect -showcerts
      1211764609:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.C;1:772:
      no peer certificate available
      No client certificate CA names sent
      SSL handshake has read 7 bytes and written 305 bytes
      New, (NONE), Cipher is (NONE)
      Secure Renegotiation IS NOT supported
      Compression: NONE
      Expansion: NONE
      No ALPN negotiated
      Protocol  : TLSv1.2 
      Cipher    : 0000 
      Key-Arg   : None 
      PSK identity: None 
      PSK identity hint: None 
      SRP username: None 
      Start Time: 1554322235 
      Timeout   : 300 (sec) 
      Verify return code: 0 (ok) 
    • While this is an abbreviated pass
      $ openssl s_client -connect -showcerts
      depth=2 C = US, O = "Entrust, Inc.", OU = See,
      	OU = "(c) 2009 Entrust, Inc. - for authorized use only",2 verify error:num=19:self signed certificate in certificate chain
      Certificate chain
      0 s:/C=CA/ST=Ontario/L=Kitchener/O=Bell Canada/ 
      i:/C=US/O=Entrust, Inc./OU=See 2012 Entrust, Inc. - for authorized use only/CN=Entrust CertifK
      -----BEGIN CERTIFICATE-----
      -----END CERTIFICATE-----
      1 s:/C=US/O=Entrust, Inc./OU=See 2012 Entrust, Inc. - for authorized use only/CN=Entrust CertifK
      i:/C=US/O=Entrust, Inc./OU=See 2009 Entrust, Inc. - for authorized use only/CN=Entrust Root C2
      -----BEGIN CERTIFICATE-----
      -----END CERTIFICATE-----
      2 s:/C=US/O=Entrust, Inc./OU=See 2009 Entrust, Inc. - for authorized use only/CN=Entrust Root C2
      i:/C=US/O=Entrust, Inc./OU=See 2009 Entrust, Inc. - for authorized use only/CN=Entrust Root C2
      -----END CERTIFICATE-----
      Server certificate
      subject=/C=CA/ST=Ontario/L=Kitchener/O=Bell Canada/ issuer=/C=US/O=Entrust, Inc.
      	/OU=See 2012 Entrust, Inc. - for authorized use only/CN=Entrust CertK
      No client certificate CA names sent
      SSL handshake has read 4579 bytes and written 623 bytes
      New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported
      Compression: NONE
      Expansion: NONE
      No ALPN negotiated
      Protocol  : TLSv1.2 
      Cipher    : AES256-GCM-SHA384 
      Session-ID: D24A4196DD1C6E36B35B4E85A5985BFA58A7541487A84F9B863926BB45BC249E 
      Master-Key: 9C14A7397DC7FB7CCF8684A4F05EC8F3F56364491E497B9CADF7FC8550F7A25861F97B12FBA1B76E68ACA20EFE50481D 
      Key-Arg   : None 
      PSK identity: None 
      PSK identity hint: None 
      SRP username: None 
      TLS session ticket lifetime hint: 300 (seconds) 
      TLS session ticket: 
      0000 - 47 b7 de fa 7c f1 cb db-0b 80 3a 58 31 21 c8 84   G...|.....:X1!.. 
      0010 - 4b 65 6b 8b 49 88 ee 49-5d 3b e0 1f f6 c1 55 81   Kek.I..I];....U. 
      0020 - ee 7d 01 2e fc 85 e7 e4-c2 b4 4e 1a d0 a4 65 b7   .}........N...e. 
      0030 - 09 3d 46 05 7e 6c 7c 21-97 df 4a 56 9f aa c7 3e   .=F.~l|!..JV...> 
      0040 - 6b 6d 68 6a c7 81 7e 07-30 70 c8 64 a6 6a 54 f1   kmhj..~.0p.d.jT. 
      0050 - 23 fb 38 4d d5 dc 83 95-95 fa c9 c5 e2 28 cc 42   #.8M.........(.B 
      0060 - a6 5b 34 ac ed 80 b0 d6-7e ae de 48 12 22 68 48   .[4.....~..H."hH 
      0070 - 15 34 ea 1e df fa 76 b3-3c 4b 2e 1d 58 7f 8b e1   .4....v.
    • most of our clients still use IE11 while our developers use Firefox or Chrome. Be sure to test with all browsers. For example, I initially set "[SSLcipherList] ALL" which prevented connections by Firefox and Chrome (complained that the negotiated protocols were too dangerous) but not IE11 (hasn't been patched in a long while)

Serving up Apache/CSWS Files from WASD HTTPd

  • caveat: I am currently looking for a quick way to replace CSWS/Apache with WASD under emergency conditions. Your map file would look quite different when using WASD on a new system
  • change the contents of file "[WASD_ROOT.local]wasd_config_map.conf" with something similar to this
    • Apache notes:
      • all the folders listed after "/dka200/apache" are folders under APACHE_ROOT:[000000] on my system
      • file "default.html" can be found in APACHE_ROOT:[MAIN] on my system
    #	basic stuff (also means we can't use these paths in Apache)
    exec	/cgi-bin/*	/cgi-bin/*
    exec+	/cgiplus-bin/*	/cgi-bin/*
    pass	/wasd_root/*	/wasd_root/*	dir=access dir=wildcard
    #	for CERN HTTPd compatibility
    map	/httpd-intenal-icons/*	/httpd/-/*
    #	other
    pass	/*/-/*	/wasd_root/runtime/*/*	cache=perm
    pass	/wasd_root/runtime/*	/wasd_root/runtime/*
    pass	/wasd_root/src/misc/*	/wasd_root/src/misc/*
    #	for access to server admin
    pass	/httpd/-/admin/
    #	for Apache compatibility on the Bell-ATS system
    set * map=root=/dka200/apache
    exec /cgi-bin/*	/cgi-bin/*
    exec /scripts/*	/scripts/*
    pass /css/*	/css/*
    pass /icons/*	/icons/*
    pass /images/*	/images/*
    pass /public/*	/public/*
    pass /jquery/*  /jquery/*
    pass /*		/main/*
    fail *
  • shutdown CSWS/Apache
  • change the ownership of Apache root
    • set def dka200:[000000]
    • set file/owner=HTTP$SERVER apache.dir
  •  change the ownership of Apache files
    • set file/owner=HTTP$SERVER [apache...]*.*;
  • start WASD
  • you are ready to go (at least with static HTML)

Scripting (serving up DCL scripts)


  • caveat: here I am referring to the scripts usually executed by the webserver on behalf of some user request (not the scripts you might find in folders like wasd_root:[startup]). Some DCL scripts might do nothing else other than run an executable (e.g. they have one line like this: "$run csmis$exe:progam.exe")
  • the scripting environment is locked down on WASD and that is probably a good thing (see my previous comments on systems setup by "the brain dead")
  • When working with Apache on most systems including Linux, Unix and OpenVMS, you can get around most webserver issues by increasing the privileges of the associated accounts.
  • The default behavior of WASD prevents you from doing this
    • remember how computers were setup before the first appearance of web servers in 1989 at CERN? No one was able to access anyone else's directories or files. Web servers were only meant to offer unrestricted access to files in a certain area of the computer. Later webserver versions attempted to add-on user authentication and authorization but the implementation was usually done in a sloppy haphazard fashion
    • scripting on WASD is usually assigned to account HTTP$NOBODY which must only have these VMS privileges: NETMBX and TMPMBX. On top of that, the account cannot be a member of the SYSTEM group. On startup, WASD will inspect these setting then will disable default scripting if it sees anything that might appear dangerous)
  • Unfortunately, over the past 20-years the CSWS/Apache on my systems have be run with more privs than NETMBX and TMPMBX. So producing a solution where WASD can be used as a drop-in replacement for CSWS/Apache required a little more effort.

Quick steps

  • step-1
    • edit file: [WASD_ROOT.local]wasd_config_global.conf
      field current contents new contents notes
      [Scripting] disabled enabled  
      [DclDetachProcess] disabled enabled  
      [DclDetachProcessPriority]   1  
      [DclScriptRunTime] .PL__ @cgi-bin:[000000]
      .PL perl
      .DLL $CGI-BIN:[000000]CGISAPI.EXE
      .CLASS @CGI-BIN:[000000]JAVA.COM
      .COM text/plain DCL procedure
      .EXE application/octet-stream executable
      append these two lines to the current list
      or replace the current list as you see fit
  • step-2 (add this line to file "STARTUP_LOCAL.COM")
    $! initial setting to start hacking
    $! initial hacking may require /watch to write more stuff to the server log file
    $ if 1.eq.0
    $ then
    $ define/system WASD_STARTUP_SERVER "/PERSONA=relaxed/SYSUAF=relaxed/Profile"
    $ else
    $ endif
  • step-3 (modify file [WASD_ROOT.local]WASD_CONFIG_MAP.CONF to look similar to this)
    #	basic stuff (also means we can't use these paths in Apache)
    exec	/cgi-bin/*	/cgi-bin/*
    exec+	/cgiplus-bin/*	/cgi-bin/*
    pass	/wasd_root/*	/wasd_root/*	dir=access dir=wildcard
    #	for CERN HTTPd compatibility
    map	/httpd-intenal-icons/*	/httpd/-/*
    #	other
    pass	/*/-/*	/wasd_root/runtime/*/*	cache=perm
    pass	/wasd_root/runtime/*	/wasd_root/runtime/*
    pass	/wasd_root/src/misc/*	/wasd_root/src/misc/*
    #	for access to server admin
    pass	/httpd/-/admin/
    # Bell-ATS notes
    # 1) we want WASD to serve up content the same way as APACHE$WWW so the
    #       server must run in persona=relaxed mode
    # 2) the folders below are required by our CSWS/Apache server
    # 3) WASD variables employ a CGIprefix of "www_" while our Apache does not
    SET     * map=root=/dka200/apache
    SET     /*              report=detailed
    SET     /scripts/* script=as=APACHE$WWW CGIprefix=
    SET     /cgi-bin/* script=as=APACHE$WWW CGIprefix=
    exec    /cgi-bin/*      /cgi-bin/*
    exec    /scripts/*      /scripts/*
    pass    /css/*          /css/*
    pass    /icons/*        /icons/*
    pass    /images/*       /images/*
    pass    /public/*       /public/*
    pass    /jquery/*       /jquery/*
    pass    /*              /main/*
    fail    *
  • restart WASD

Properly enabling Server Admin

    current contents new contents notes

    [ServiceAdmin] enabled
    append the stanza in red to
    enable Service Admin on port: 44443
    current contents new contents notes
    ["Web Admin"=VMS]
    #       only from Neil's Desktop
    #/httpd/-/admin/*       r+w,
    #/wasd_root/local/*     r+w,
    #       only from Neil's subnet
    /httpd/-/admin/*        r+w,
    /wasd_root/local/*      r+w,
    insert a block like this
  • restart WASD

Supporting gSOAP

  • before you begin this section, ensure that gSOAP is already installed on your system. Start by typing this command:
    $ show logical gsoap_root
  • if that command doesn't work then you will need to acquire an appropriate kit (Alpha or Itanium) from here:
    • John Apps has retired but Brett Cameron is still answering email requests
    • more gSOAP information can be found here: OpenVMS-Notes: AXIS2
  • unzip
    $! DCL script to unzip gSOAP support for WASD
    $! this is an rx2660 (Itanium2)
    $ define/job yada CSMIS$USER3:[ADMCSM.NEIL._WASD]	! files where downloaded here
    $ set def DKA200:[000000]				! move to root of disk dka200
    $ set def [WASD_ROOT]					!
    $ unzip				!
  • read this
  • install
    $ @ WASD_ROOT:[EXAMPLE]WASDVERBS.COM		! create some verbs required for the build script
    $ @BUILD_GSOAPRTE				! can link-only or compile-and-link
  • build gSOAP example programs found the calc folder under WASD (these are slightly different from examples found under gsoap$root)
    $ set def WASD_ROOT:[SRC.GSOAP.CALC]		! navigate here
    $ edit/read calc.c				! inspect this file (basis of the service)
    $ edit/read calcclient.c			! inspect this file (the standalone client)
    $! note: if you enable interface logging: soap_set_recv_logfile(),
    $!	soap_set_sent_logfile(), soap_set_test_logfile()
    $!	then you must link against gsoapdbg.olb rather than gsoap.olb 
    $ @build					!
    $!	yields:	soap_calc_share.exe		! similar to the Brett Cameron's demo
    $!		soap_calc_cgiplus.exe		! a cgi+ variant
    $!		calcclient.exe			! DCL-based client
  • changes to the mapping file
    exec	/cgi-bin/*	/cgi-bin/*
    exec+	/cgiplus-bin/*	/cgi-bin/*
    # Default
    pass	/wasd_root/*	/wasd_root/*	dir=access dir=wildcard
    # for CERN HTTPd icon compatibility
    map	/httpd-internal-icons/*		/httpd/-/*
    # other
    pass	/*/-/*	wasd_root/runtime/*/*	cache=perm
    pass	/wasd_root/runtime/*		/wasd_root/runtime/*
    pass	/wasd_root/scr/misc/*		/wasd_root/src/misc/*
    # access to server admin
    pass	/httpd/-/admin/*
    # use this mapping for wasd gsoap example files copied to /cgi-bin
    exec+	/soapdemo/soap_calc_sha*	(cgi_exe:gsoaprte)/cgi-bin/soap_calc_sha*
    exec+	/soapdemo/soap_calc_cgi*	(cgi_exe:gsoaprte)/cgi-bin/soap_calc_cgi*
    #	alternative access notes:
    #		$copy soap_calc_share.exe   calc1.exe
    #		$copy soap_calc_cgiplus.exe calc2.exe
    exec+	/calc*				(cgi_exe:gsoaprte)/cgi-bin/calc*
  • copying files to their target directories then use the DCL-based client to test the service
    $ set def WASD_ROOT:[SRC.GSOAP.CALC]
    $ dir *.exe/col=1
    Total of 3 files.
    $ copy SOAP_CALC_CGIPLUS.EXE wasd_root:[cgi-bin]
    $ copy SOAP_CALC_SHARE.exe   wasd_root:[cgi-bin]
    $ copy SOAP_CALC_SHARE.exe   wasd_root:[cgi-bin]calc1.exe
    $ test
    Requires: $ CALC_URL = ""
    $ CALC_URL = ""
    $ test
    Usage: [add|sub|mul|div|pow] num num
    $ test add 123 456
    result = 579


Back to Home
Neil Rieck
Waterloo, Ontario, Canada.