[Info-vax] An HP SSL mystery

[Steven Schweda]

   For the mystery lovers out there...

   The generic OpenSSL kit uses a bunch of dollar-free
logical names, such as:

  "OPENSSL" = "SSLINCLUDE:"
  "SSLCERTS" = "sslroot:[certs]"
  "SSLEXE" = "sslroot:[ALPHA_exe]"
  "SSLINCLUDE" = "sslroot:[include]"
  "SSLLIB" = "sslroot:[ALPHA_lib]"
  "SSLPRIVATE" = "sslroot:[private]"
  "SSLROOT" = "ALP$DKC100:[UTILITY.SOURCE.OPENSSL.1_0_1I.]"

   The HP SSL kit uses a bunch of dollary logical names, such
as:

  "OPENSSL" = "SSL$INCLUDE:"
  "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.]"

   If one were to look closely at the HP SSL shared images,
which would one expect to find there, SSL$ROOT?

ALP $ search sys$share:ssl$*32.exe ssl$root
%SEARCH-I-NOMATCHES, no strings matched

   Nope.  But surely not the generic SSLROOT...

ALP $ search sys$share:ssl$*32.exe sslroot

******************************
SYS$COMMON:[SYSLIB]SSL$LIBCRYPTO_SHR32.EXE;1
[...]
><NUL><NUL><NUL><NUL><NUL><NUL><NUL>SSLROOT:[ENGINES]<NUL><NUL><NUL><NUL><NUL><N
[...]
L><NUL><NUL><NUL><NUL><NUL>SSLCERTS:cert.pem<NUL><NUL><NUL><NUL><NUL><NUL><NUL>S
SLROOT:[000000]<NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL>CRYPTO$RES:[OSSL.BUILD_05
[...]


   Why would anyone notice this?  As it happens, some
unfortunate fellow tried to build Wget using the HP SSL kit,
and discovered that the HP [Open]SSL code in the resulting
executable could not find its own configuration file.  The
symptom looked like this:

REX $ mcr [-.SRC.IA64L]wget --no-check-certificate https://google.com
--2015-06-22 14:16:13--  https://google.com/
Auto configuration failed
551552061:error:02001006:system library:fopen:no such device or address:BSS_FILE
:126:fopen('SSLROOT:[000000]openssl.cnf','r')
551552061:error:2006D002:BIO routines:BIO_new_file:system lib:BSS_FILE:131:
551552061:error:0E078002:configuration file routines:DEF_LOAD:system lib:CONF_DE
F:199:

   'Why, if it's using HP SSL, is it looking for
"SSLROOT:[000000]openssl.cnf", and not
"SSL$ROOT:[000000]openssl.cnf"?', I hear you cry.  The search
for the reason behind this led to the discovery of two places
in the OpenSSL source code (and in the corresponding HP SSL
source code) where "SSLROOT" appears (and none where
"SSL$ROOT" appears).  Thus it appears that the HP SSL shared
images may rely on a logical name which the HP SSL startup
script (SYS$STARTUP:SSL$STARTUP.COM) does not define.

   The quick (obvious?) work-around seems to do the job:
      define SSLROOT SSL$ROOT

   So, is this a long-standing bug in HP SSL, or am I missing
something obvious (again), or what?  (I noticed nothing
relevant in the HP SSL release notes.)

   Observed with HP AXPVMS SSL V1.4-502 and HP I64VMS SSL
V1.4-502, and in some older 1.4-3?? version (which I updated
to -502, to no avail).