16-Jun-2017

WASD 11.1 running!
Contacted mark Daniel directly on the issue and offered him access to the server to have a look at the live environment. As it turned out, there were a few things.
First, the SSL kit installed (1.4) is still based om 0.8.8, where WASD 11.1 requires 1.0.2. Actually, 11.0 ran TLS as well but that one is less restrictive. Than, I remembered why the later version (named SSL!) wasn;t installed – I downloaded the kit and it explicitly stated that this one is incompatibel with the 1.4 version (installed) and would require patches on a number of products – and I canbnot get them – so that’s why I didn’t. (having said that: it’s clear why this kit has a different profix (SSL1 in stead of the expected SSL).
Mark had a diffeernt approach: Het got the certificates I need from Lets’s Encrypt and installed them. Now the secure sites were accessable. Heft left 11.1 running so I could get on.
Well, that was this morning. When I found out that both Firefox and Chrome will access the first secure site acessed, and keep that site at hand when you access another. For isntance: accessing webmail (and login), next access the operator pages, you will have to login on webmail again (it will do so directly since you already did). Otherwise: first login at the operator pages will use that loigin for webmail as well – and you’ll end up in the opertaor page, even when the URL states webmail….

This happpened when HTTP/2 enabled. Without, it seemed fine. Se we left it that way – for the time being.
Not until a few hours later, when Mark notices a missing bit in the HTTP/2 processing on secure sites – a bit hidden in the specs. That has been fixed now, and so |I’m a bit ahead of other WASD users :). And HTTP/2 enabled.

10-Jun-2017

New WordPress
Latest version of WordPress (4.8) has been installed and all blogs are now on this version.

But no new server
But getting WASD 11.1 running properly still doesn’t work, at least, for the secured sites. It could have been a matter of updates to the configuration files. Mine were outdates – had some obsolete options and missed some other ones, including the SSL ones, but the server would fall back on internal defaults ao it should work. But it made no difference.
Checking access using the WASD_SSL package (both with the openssl image and over the web) accessing the secured ports is file. But when started, these still fail to setup a connection. No signal AT ALL, not in the page, nor in the server logs….WATCH doesn’t show anything either, just that the request is coming in, some data is sent and the connection is closed….

07-Jun-2017

More on WASD 11.1 and TLS,/font>
I Looked into some startup files, I may need other files; HP’s SSL package is still based on 9.8.0, where WASD-SSL is based on OpenSSL 1.0.2. The procedure that starts WASD defines these files to be used, so that may cause the problems. However, I could not find files to be installed or referenced in startup. So I asked the WASD mailing list.

02-Jun-2017

Updates
#1: WordPress / Akismet: Without trouble. Startup updates to reflect the change.
#2: HP’s OpenSSL package – this could be the cause of problems with WASD 11.1. Just cheking whether this did the trick: I may need to redo the update procedure. 11.0 works with this new version, but 11.1 doesn’t when accessing one of the secured sites. Strange, however: in demo mode it DOES work, without rebuilding the server….
Current installation of OpenSSL:
$ sho sym openssl
OPENSSL == "$WASD_ROOT:[SRC.OPENSSL-1_0_2K.ALPHA.EXE.APPS]OPENSSL.EXE"
$ openssl version
OpenSSL 1.0.2k 26 Jan 2017

and after HP’s installation:
$ opensslHP :== $SSL$ROOT:[ALPHA_EXE]OPENSSL.EXE
OpenSSL 0.9.8zh 3 Dec 2015
SSL for OpenVMS V1.4 Feb 5 2016.

This should be the right version: I checked HPE.com, dile is version is 1.4-0503, installed today:
$ prod show hist
------------------------------------ ----------- ----------- --- -----------
PRODUCT                              KIT TYPE    OPERATION   VAL DATE
------------------------------------ ----------- ----------- --- -----------
HP AXPVMS SSL V1.4-503               Full LP     Install
     Val 04-JUN-2017
HP AXPVMS SSL V1.4-502               Full LP     Remove       -  04-JUN-2017
HP AXPVMS SSL V1.4-502               Full LP     Install
     Val 05-JAN-2016

But still, it won’t connect.
So I recreated the DH_keyfiles (512, 1024 and 2048 bit), and retried: Now it’s OK running the WASD version – using specifications I set up some time ago):

$ openssl s_client -connect www.grootersnet.nl:443
CONNECTED(00000003)

depth=0 C = NL, ST = UT, L = leusden, O = Grootersnet, OU = Webservices, CN = *.grootersnet.nl, emailAddress = system@grootersnet.nl
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = NL, ST = UT, L = leusden, O = Grootersnet, OU = Webservices, CN = *.grootersnet.nl, emailAddress = system@grootersnet.nl
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/C=NL/ST=UT/L=leusden/O=Grootersnet/OU=Webservices/CN=*.grootersnet.nl/emailAddress=system@grootersnet.nl
   i:/C=AU/ST=SA/L=Adelaide/O=WASD HTTPd CA Cert/OU=OpenSSL 0.9.8 Testing Only/CN=WASD VMS Hypertext Services/emailAddress=Mark.Dani
el@wasd.vsm.com.au
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=/C=NL/ST=UT/L=leusden/O=Grootersnet/OU=Webservices/CN=*.grootersnet.nl/emailAddress=system@grootersnet.nl
issuer=/C=AU/ST=SA/L=Adelaide/O=WASD HTTPd CA Cert/OU=OpenSSL 0.9.8 Testing Only/CN=WASD VMS Hypertext Services/emailAddress=Mark.Da
niel@wasd.vsm.com.au
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2132 bytes and written 433 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 5C66A91090EB2A8444AEB1AA30E8F7FA8EE674442E2EC4042E54E7FD05197FFB
    Session-ID-ctx:
    Master-Key: 1463D1FBAA5D6B2A7B052B15187FD0E01B784B8BFC5F1C7B678FCC1074B87C2C9E6CD49A30BAAD496CE23CCC3DA0937E
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    Start Time: 1496607150
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)
openssl s_client -connect www.grootersnet.nl:443
/
<HTMLglt;
<HEADglt;
<TITLEglt;ERROR 501 Not Implemented</TITLEglt;
</HEADglt;
<BODY LINK="#0000cc" VLINK="#0000cc"glt;
<FONT SIZE=+1glt;
<Bglt;ERROR 501</Bglt;  -  The requested action is not implemented by this server.
</FONTglt;
<Pglt;Additional information: 
<A HREF="/httpd/-/status1xx.html"glt;1<Iglt;xx</Iglt;</Aglt;, 
<A HREF="/httpd/-/status2xx.html"glt;2<Iglt;xx</Iglt;</Aglt;, 
<A HREF="/httpd/-/status3xx.html"glt;3<Iglt;xx</Iglt;</Aglt;, 
<A HREF="/httpd/-/status4xx.html"glt;4<Iglt;xx</Iglt;</Aglt;, 
<A HREF="/httpd/-/status5xx.html"glt;5<Iglt;xx</Iglt;</Aglt;, 
<A HREF="/httpd/-/statushelp.html"glt;Help</Aglt;
<Pglt;<HR WIDTH=85% ALIGN=left SIZE=2 NOSHADEglt;
<ADDRESSglt;WASD/11.1.0 Server at www.grootersnet.nl Port 443</ADDRESSglt;
</BODYglt;
</HTMLglt;closed

but now the HP version fails:
$ opensslHP s_client -connect www.grootersnet.nl:443
CONNECTED(00000005)
539100522:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:S23_CLNT:579:
$

but where I would expect I could access the secured sites, but that still fails. if this has to do with logical SSL$ROOT, it makes sense:
$ sho log ssl*

(LNM$PROCESS_TABLE)

(LNM$JOB_82670140)

(WASD_TABLE)

(LNM$GROUP_000001)

(LNM$SYSTEM_TABLE)

"SSL$CERT" = "SSL$ROOT:[DEMOCA.CERTS]"
"SSL$CERTS" = "SSL$ROOT:[DEMOCA.CERTS]"
"SSL$COM" = "SSL$ROOT:[COM]"
"SSL$CONF" = "SSL$ROOT:[DEMOCA.CONF]"
"SSL$CRL" = "SSL$ROOT:[DEMOCA.CRL]"
"SSL$EXAMPLES" = "SYS$COMMON:[SYSHLP.EXAMPLES.SSL]"
"SSL$EXE" = "SSL$ROOT:[Alpha_EXE]"
"SSL$INCLUDE" = "SSL$ROOT:[INCLUDE]"
"SSL$KEY" = "SSL$ROOT:[DEMOCA.CERTS]"
"SSL$KEYS" = "SSL$ROOT:[DEMOCA.CERTS]"
"SSL$PRIVATE" = "SSL$ROOT:[DEMOCA.PRIVATE]"
"SSL$ROOT" = "SYS$SYSDEVICE:[VMS$COMMON.SSL.]"

(LNM$SYSCLUSTER_TABLE)

(DECW$LOGICAL_NAMES)
$

Restart of the server makes no difference….Maybe I need to change a few things here.

01-Jun-2017

Monthly maintenance
The standard script didn’t show up anything weird:

PMAS statistics for May
Total messages    :   2929 = 100.0 o/o
DNS Blacklisted   :      0 =    .0 o/o (Files:  0)
Relay attempts    :    194 =   6.6 o/o (Files: 31)
Accepted by PMAS  :   2735 =  93.3 o/o (Files: 31)
  Handled by explicit rule
         Rejected :   1843 =  67.3 o/o (processed),  62.9 o/o (all)
         Accepted :    168 =   6.1 o/o (processed),   5.7 o/o (all)
  Handled by content
        Discarded :    404 =  14.7 o/o (processed),  13.7 o/o (all)
     Quarantained :    285 =  10.4 o/o (processed),   9.7 o/o (all)
        Delivered :     35 =   1.2 o/o (processed),   1.1 o/o (all)

Surprisingly, the number of relay attempts has dropped; most (158) occurred on 25-MAY-2017 between 08:52:48.06 and 09:02:03.88; all “sent” from (fake) users in my domain to be received by 1029mandaditos@gmail.com. from address 212.129.30.113 – seems to be hosted in France (astucesaclashofclans.fr) but the domain of the PTR record is Brazilian (plmc-113-30-129-212.grandesnoticias.com.br). The address raises red flags in 6 blacklsist.

Another issue that came up when examining the router logs. Not the number (well, a new 25K+ file every 2 or 3 days, need to check out earlier files) but that may have to do with the new router, though it should be compatible with the older one. Except that its throughput is way up, so it can handle more traffic….
But that is not the point.
What I found was, that, for the current file, ever 5 minutes or so, my workstation scans port 8612 in my network – both IP4 (LAN -> LAN) and IP6 (L:AN -> WAN). These are short messages (20 bytes) but what causes it? Searching the internet I found it is a CANON protocol, and I did install new Canon drives last week…I looked into the services and found a Canon service running which might be the cause – so I stopped it. But that doesn’t help…But looking on the resource manager, I located another one: CNMNSST.exe, and that indeed is the program I’m looking for. It doesn’t do much harm, according the descriptions: Hardly any CPU, memory or disk/IO: but it doesn’t mention it will constantly scan the network for a printer. This si something I need to dig into: It’s started by the task manager so there might be something to tweak.

WASD Update failure: Source located.
Actually, the update is fine. It’s just that secures sites are no longer accusable. Mark gave me a hint that I flowed up:

$ openssl :== $ SSL$ROOT:[ALPHA_EXE]openssl.exe
$ openssl s_client -connect www.grootersnet.nl:443

on 11.0.2 (what I’m running now), this starts the handshake:

$ openssl s_client -connect www.grootersnet.nl:443
CONNECTED(00000005)
...
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
(etcetera etcetera)

after which a command can be entered.

On 11.1:

$ openssl s_client -connect www.grootersnet.nl:443
CONNECTED(00000005)
539094439:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:S23_CLNT:593:

And that’s it.

Mark’s comment:

Incompatible version (see below).

(because there was more…)

Might be an SSL issue?

$ OpenSSL version
OpenSSL 0.9.8ze 15 Jan 2015
SSL for OpenVMS V1.4 Feb 18 2015.
$

Yes. This looks like the obsolete HP SSL kit

|$ mcr SYS$COMMON:[SSL.ALPHA_EXE]OPENSSL.EXE version OpenSSL 0.9.8ze 15
|Jan 2015 SSL for OpenVMS V1.4 Feb 18 2015.

I get the same result using that version

There are some things to consider now, but first Update WordPress and Akismet 🙂