Alternatively, files containing emphemeral keys generated freshly with each release, may be copied from the WASD OpenSSL package using $ COPY WASD_ROOT:[SRC.OPENSSL-n_n_n.WASD.CERT]DH_PARAM_*.PEM WASD_ROOT:[LOCAL] (Session Resumption\hd_ssl_session)

When a TLS/SSL connection is initiated an expensive handshake (in terms of time and compute) is required to establish the cryptographic and other elements of the connection. Mitigation of this expense is undertaken by allowing the resumption of a previous session (abbreviating the handshake exchanges) using connection state stored either at the server or at the client. (UNNUMBERED) (Session Ticket\BOLD)

This TLS extension provides the connection state to the client, encrypted with keys available only to the server. The client stores the (encrypted) state and when (re-)connecting to the server provides that ticket in the initial part of the handshake. The server decrypts the ticket and if valid expedites the connection by resuming the previously negotiated session. This is the more modern, almost universally supported mechanism and is generally enabled by default.

Session tickets introduce a potential vulnerability to TLS security, in particular to the benefits of Forward Secrecy (PFS). If the ticket can be compromised, through theft of the keys or brute-force decryption attack, the entire session becomes vulnerable to attack. It is therefore advised to periodically rotate (change) the keys used by the server to encrypt the tickets. WASD does this every (RFC recommended) 24 hours, at midnight (local time).

Where a site is provided by multiple servers and connections distributed between these, session resumption using tickets relies on each server using the same keys. The current keys must be distributed to each server (using a secure mechanism) and this performed every time the keys are rotated. WASD uses the DLM to perform this for multiple per-node and cluster-wide instances as applicable. (Session ID\BOLD)

In a full handshake the server sends a Session ID (unique, non-repeating value) as part of the handshake. On a subsequent connection the client can pass this session ID back to the server when connecting. To support session resumption via session IDs the server must maintain a cache that maps past session IDs to those sessions' states. The cache has limited capacity and is expensive for the server to maintain. If the session ID is still available in the cache the session can be resumed. This is the original session resumption mechanism.

Where a single WASD instance is involved the session cache is implemented in-memory. With multiple instances on a single node it is provided across those instances using a shared global section. The cacpacity of this shared cache is determined by the WASD_CONFIG_GLOBAL directives [SSLinstanceCacheMax] and [SSLinstanceCacheSize] directives. There is no cluster-wide session cache. When multiple instances are in use the shared session cache is enabled by default. Session ID caching may be globally disabled by setting [SSLsessionCacheMax] to -1.

With Session Tickets being the more modern, flexible and efficient solution to session resumption (and being available cluster-wide) it is recommended that WASD sites disable Session ID caching.

The default maximum period for session reuse is five minutes. This may be set globally using the [SSLsessionLifetime] directive or on a per-service basis using [ServiceSSLsessionLifetime].

To some extent, the relatively long-lived connections and lower concurrency with HTTP/2 means the importance of session resumption in improving request latency and connection overhead is reduced. (Strict Transport Security\hd_ssl_hsts)

HTTP Strict Transport Security (HSTS) is a security policy mechanism which helps protect sites against protocol downgrade attack and cookie hijacking. It allows web servers to declare that browsers and other complying agents should only interact using secure (TLS) HTTP connections and never via clear-text HTTP. HSTS is an IETF standard specified in RFC 6797.

When global configuration directive [SSLstrictTransSec] is non-zero, or per-service configuration directive [ServiceSSLstrictTransSec] is non-zero, or a path is (SET response=sts=()), TLS/SSL HTTP responses include a (Strict-Transport-Security: max-age=(seconds)) header field. Conforming agents note this period and refuse to communicate with the site via clear-text HTTP for the period represented by the integer number of seconds specified. (SSL Server Certificate\hd_ssl_server_cert)

The server certificate is used by the browser to authenticate the server against the server certificate Certificate Authority (CA), in making a secure connection, and in establishing a trust relationship between the browser and server. By default this is located using the WASD_CONFIG_GLOBAL [SSLcert] or WASD_CONFIG_SERVICE [ServiceSSLcert] configuration directive, the WASD_CONFIG_SSL_CERT logical name, or using the /SSL= command-line qualifier, however if required. Each SSL service can have an individual certificate configured as in the example above. (SSL Private Key\hd_ssl_private_key)

The (private key) is used to validate and enable the server certificate. A private key is enabled using a (secret), a password. It is common practice to embed this (encrypted) password within the private key data. This private key can be appended to the server certificate file, or it can be supplied separately. If provided separately it can be located using the WASD_CONFIG_GLOBAL [SSLkey] or WASD_CONFIG_SERVICE [ServiceSSLkey] configuration directive, tor using the WASD_CONFIG_SSL_KEY logical. When the password is embedded in the private key information it becomes vulnerable to being stolen as an enabled key. For this reason it is possible to provide the password separately and manually.

If the password key is not found with the key during startup the server will request that it be entered at the command-line. This request is made via the HTTPDMON (STATUS:) line (see (HREF=[-.config]config.sdml!../config/#hd_opcom)([-.CONFIG]DOC_config.sdml)), and if any OPCOM category is enabled via an operator message. If the private key password is not available with the key it is recommended that OPCOM be configured, enabled and monitored at all times.

When a private key password is requested by the server it is supplied using the /DO=SSL=KEY=PASSWORD directive ((hd_admin_do_cli)). This must be used at the command line on the same system as the server is executing. The server then prompts for the password. Enter private key password []: The password is not echoed. When entered the password is securely supplied to the server and startup progresses. An incorrect password will be reprompted for twice (i.e. up to three attempts are allowed) before the startup continues with the particular service not configured and unavailable. Entering a password consisting of all spaces will cause the server to abort the full startup and exit from the system. (SSL Virtual Services\hd_ssl_config_virtual)

Multiple virtual SSL services (https:) sharing the same or individual certificates (and other characteristics) can essentially be configured against any host name (unique IP address or host name alias) and/or port in the same way as standard services (http:).

WASD SSL implements (Server Name Indication\BOLD) (SNI), an extension to the TLS protocol that indicates what hostname the client is attempting to connect to at the start of the handshaking process. This allows a server to present multiple certificates on the same IP address and port number and hence allows multiple secure (HTTPS) websites (or any other Service over TLS) to be served off the same IP address without requiring all those sites to use the same certificate.

When the client presents an SNI server name during SSL connection establishment, WASD searches the list of services it is offering for an SSL service (the first hit) operating with a name matching the SNI server name. If matched, the SSL context (certificate, etc.) of that service is used to establish the connection. If not matched, the service the TCP/IP connection originally arrived at is used. (SSL Access Control\hd_ssl_access_control)

When authorization is in place ((cr_authorization)) access to username/password controlled data/functionality benefits enormously from the privacy of an authorization environment inherently secured via the encrypted communications of SSL. In addition there is the possibility of authentication via client X.509 certification ((hd_ssl_x509_auth)). SSL may be used as part of the site's access control policy, as whole-of-site, see (hd_auth_policy), or on a per-path basis (see (HREF=[-.config]config.sdml!../config/#cr_mapping_rule)([-.CONFIG]DOC_config.sdml)). (--------------------------------------------------------------------) (Authorization Using X.509 Certification\hd_ssl_x509_auth)

The server access control functionality (authentication and authorization) allows the use of (public key infrastructure) (PKI) X.509 v3 client certificates for establishing identity and based on that apply authorization constraints. See (cr_authorization) for general information on WASD authorization and (hd_auth_file) for configuring a X509 realm. (hd_ssl_ref) provides introductory references on public-key cryptography and PKI.

A client certificate is stored by the browser. During an SSL transaction the server can request that such a certificate be provided. For the initial instance of such a request the browser activates a dialog requesting the user select one of any certificates it has installed. If selected it is transmitted securely to the server which will usually (though optionally not) authenticate its Certificate Authority to establish its integrity. If accepted it can then be used as an authenticated identity. This obviates the use of username/password dialogs. (Important) Neither username/password nor certificate-based authentication addresses security issues related to access to individual machines and stored certificates, or to password confidentiality. Public-key cryptography only verifies that a private key used to sign some data corresponds to the public key in a certificate. It is a user responsibility to protect a machine's physical security and to keep private-key passwords secret.

The initial negotiation and verification of a client certificate is a relatively resource intensive process. Once established however, OpenSSL sessions are usually either stored in a cache or stored encrypted withing the client, reducing subsequent request overheads significantly. Each session has a specified expiry period after which the client is forced to negotiate a new session. This period is adjustable using the ([LT:integer]) and ([TO:integer]) directives described below. (X.509 Certificate Renegotiation\hd_ssl_x509_renegotiation)

An X.509 client certificate is requested at either TLS/SSL connection establishment (WASD_CONFIG_GLOBAL [SSLverifyPeer], WASD_CONFIG_SERVICE [ServiceSSLverifyPeer]) or once the request has been made and assessed against authorisation rules. If an X509 realm controls access to the resources then the TLS/SSL connection is queried for an X.509 client certificate to authenticate the client and authorise the access.

This is performed via a TLS/SSL renegotiation and for this the connection must have been cleared of request data. In the case of a HEAD, GET, OPTIONS, etc. request, this already has implicitly occurred by there being no request body. For POST, PROPFIND, PUT, etc. requests, the client most likely already will be transmitting the request body. This ((application data)) must be absorbed before the client certificate renegotiation can be performed.

In avoiding disruption to the current request, any request body must be buffered (in full, based on the content length specified in the header) before issuing the renegotiation. This consumes memory and potentially large quantities. The default maximum buffer space is 1MB. The maximum request body size and hence maximum memory accomodated can be configured using the per-service WASD_CONFIG_SERVICE [ServiceSSLverifyDataMax] directive, or the global WASD_CONFIG_GLOBAL configuration directive [SSLverifyDataMax].

Where a request with a body exceeds the maximum allowed buffer space the authorisation fails. This can be observed using WATCH. Where very large files are being sent the only solution is to first authenticate with a request without a body (e.g. using OPTIONS) then using the persistent connection and associated X.509 authentication perform the PUT or POST. (Features\hd_ssl_x509_features)

WASD provides a range of capabilities when using X.509 client certificates. (UNNUMBERED) (By Service - \BOLD) all SSL connections to such a service will be requested to supply a client certificate during the initial SSL handshake. This is more efficient than requesting later in the transaction, as happens with per-resource authorization. A client cannot connect successfully to this type of service without supplying an acceptable certificate. (By Resource - \BOLD) using authorization rules in the WASD_CONFIG_AUTH file specifying a path against an [X509] realm causes the server to suspend request processing and renegotiate with the client to supply a certificate. If a suitable certificate is supplied the request authorization continues with normal processing. This obviously incurs an additional network transaction. (Optional access control - \BOLD) once an acceptable certificate is supplied it can be subject to further access control by matching against its contents. The (Issuer) (CA) and the (Subject) (client) (Distinguished Name) (DN) has various components including the name of the organization providing the certificate (e.g. (VeriSign), (Thawte)), location, common name, email address, etc. Those certificates matching or not matching the parameters are allowed or denied access. (Certificate verification - \BOLD) by default supplied certificates have their CA verified by comparing to a list of recognised CA certificates stored in a server configuration file. If the CA component of the client certificate cannot be verified the connection is terminated before the HTTP request can begin. Although this is obviously required behaviour for authentication there may be other circumstances where verification is not required, a certificate content display service for instance. WASD optionally allows non-verified certificates to be used on a per-resource basis. ((Fingerprint) REMOTE_USER - \BOLD) when a certificate is accepted by the server it generates a unique (fingerprint) of the certificate. By default, this 32 digit hexadecimal number is used by the server as an (effective username), one that would normally be supplied via a username/password dialog (as an alternative see the section immediately below). This effective username becomes that available via the CGI variable REMOTE_USER. Although a 32 digit number is not particularly site-administrator friendly it is a (unique) representation (MD5 digest) of the individual certificate and can be used in WASD_CONFIG_AUTH access-restriction directives and included in group lists and databases for full WASD authorization control. (CN/DN record REMOTE_USER - \BOLD) provides an alternative to using a (fingerprint) REMOTE_USER. Using the [RU:/(record)=] conditional (see below) is becomes possible to specify that the remote-user string be obtained from the specified record of the client certificate subject field. Note that there is a (fairly generous) size limitation on the user name and that any white-space in such a record is converted to underscores. Although any record can be used the more obvious candidates are /O=, /OU=, /CN=, /S=, /UID= and /EMAIL=. Note that (even with the default CA verfication) the certificate CAs that this is possible against should be further constrained through the use of a [IS:/(record)=(string)] conditional (see example below). (Subject Alternative Name REMOTE_USER - \BOLD) a common X509 V3 extension for providing identifying data in a certificate, can also be used to derive the remote user string. (X509 extension REMOTE_USER - \BOLD) the content of any other extension field suitably filtered. (Subject Alternative Name and Other Extensions\hd_ssl_x509_san)

The basic syntax for this field is the full extension name, and the short-hand equivalent. [X509] /VMS/* r+w,param="[ru:X509v3_subject_Alternative_Name]" /VMS/* r+w,param="[ru:X509v3_SAN]"

The Subject Alternative Name (SAN) extension (in common with many others) may contain multiple data elements, each with a leading name, a colon, and a (if multi line) carriage-control terminated value. WASD parses these into unqiue fields using keywords fixed in function SesolaCertKeyword() and the site configurable logical name WASD_X509_EXTENSION_KEYWORDS value. To select one of these fields, for example the common (Microsoft) user principal name (UPN), append the required field name to the extension name as shown in the following example (includes "shorthand" equivalents, along with the underscore and equate variants). Note that the identifying name match is not case sensitive. [X509] /VMS/* r+w,param="[ru:X509V3_Subject_Alternative_Name_UserPrincipalName]" /VMS/* r+w,param="[ru:X509V3_Subject_Alternative_Name=UserPrincipalName]" /VMS/* r+w,param="[ru:X509v3_SAN_UPN]" /VMS/* r+w,param="[ru:X509v3_SAN=UPN]" /VMS/* r+w,param="[ru:X509V3_Subject_Alternative_Name_rfc822Name]" /VMS/* r+w,param="[ru:X509V3_Subject_Alternative_Name=rfc822Name]" /VMS/* r+w,param="[ru:X509v3_SAN_822]" /VMS/* r+w,param="[ru:X509v3_SAN=822]"

Object Identifiers (OIDs) may be used for either record and field name (if an unknown otherName) by prefixing with (OID_). For example, the SAN may be alternatively selected, and the (Microsoft) UPN, as in the following examples. /VMS/* r+w,param="[ru:OID_2_5_29_17]" /VMS/* r+w,param="[ru:OID_2_5_29_17_UPN]" /VMS/* r+w,param="[ru:OID_2_5_29_17=UPN]" /VMS/* r+w,param="[ru:X509v3_SAN_OID_1_3_6_1_20_2_3]" /VMS/* r+w,param="[ru:X509v3_SAN_OID=1_3_6_1_20_2_3]" (Extension Visibility\hd_ssl_x509_extensions)

X509 certificate extensions are in general visible from WATCH and accessible via CGI variables (when enabled using SET (SSLCGI=apache_mod_ssl_extens) and (SSLCGI=apache_mod_ssl_client) path mappings). The identifying names derived from X509 extensions are built of the alphanumerics in the element names. Non-alphanumerics (e.g. spaces) have underscores substituted. Multiple underscores are compressed into singles. Where elements have identical names the first multiple has TWO underscores and the digit two appended, the second mutiple, two underscores and three appended, etc. (X509 Configuration\hd_ssl_x509_config)

Of course, the WASD OpenSSL component must be installed and in use to apply client X.509 certificate authorization. There is general server setup, then per-service and per-resource configuration. (General Setup\hd_ssl_x509_config_general)

Client certificate authorization has reasonable defaults. If some aspect requires site refinement the WASD_CONFIG_GLOBAL [SSL..] directives (see ([-.CONFIG]DOC_config.sdml)) or command-line /SSL= qualifier parameters can provide per-server defaults. (UNNUMBERED) (CACHE=integer) sets the session size (128 entries by default) (CAFILE=file-name) sets the location of the CA verification store file (also can be set via WASD_CONFIG_SSL_CAFILE logical). (TIMEOUT=integer) sets the session expiry period in minutes (5 by default) (VERIFY=integer) sets the depth to which client certificate CAs are verified (default is 10)

The location of the CA verification file can also be determined using the logical name WASD_CONFIG_SSL_CAFILE. The order of precedence for using these specifications is (NUMBERED) per-service configuration using WASD_CONFIG_SERVICE or WASD_CONFIG_GLOBAL per-server using /SSL=CAFILE=filename per-server using WASD_CONFIG_SSL_CAFILE (By Service\hd_ssl_x509_config_service)

The WASD_CONFIG_SERVICE directive is provided for per-service CA file specification, if necessary allowing different services to accept a different mix of CAs. [[https://the.example.com:443]] [ServiceSSLVerifyPeer] enabled [ServiceSSLVerifyPeerCAfile] WASD_ROOT:[LOCAL]CA_THE_HOST_NAME.TXT (By Resource\hd_ssl_x509_config_resource)

Client certificate authorization is probably most usefully applied on a per-resource (per-request-path) basis using WASD_CONFIG_AUTH configuration file rules. Of course, per-resource control also applies to services that always require a client certificate (the only difference is the certificate has already been negotiated for during the initial connection handshake). The reserved realm name (X509) activates client certificate authentication when a rule belonging to that realm is triggered. The following example shows such a rule providing read access to those possessing any verified certificate. [X509] /path/requiring/cert/* r

Optional directives may be supplied to the X.509 authenticator controlling what mode the certificate is accepted in, as well a further access-restriction rules on specifically which certificates may or may not be accepted for authorization. Such directives are passed via the (param=) mechanism. The following real-life example shows a script path requiring a mandatory certificate, but not necessarily having the CA verified. This would allow a certificate display service to be established, the ([to:EXPIRED]) directive forcing the client to explicitly select a certificate with each access. [X509] /cgi-bin/client_cert_details r,param="[vf:OPTIONAL][to:EXPIRED]"

A number of such directives are available controlling some aspects of the certificate negotiation and verification. The ([LT:integer]) directive causes a verified certificate selection to continue to be valid for the specified period as long as requests continue during that period (lifetime is reset with each access). (UNNUMBERED) [DP:integer] verify certificate CA chain to this depth (default 10) [LT:integer] verified certificate lifetime in minutes (disabled by default) [RU:/record=] derive the remote-user name from the specified certificate subject field DN record [TO:integer] session cache entry timeout in minutes (default 5) [TO:EXPIRED] session cache entry is forced to expire (initating renegotiation) [VF:NONE] no certificate is required (any existing is cancelled) [VF:OPTIONAL] certificate is required, CA verification is not required [VF:REQUIRED] the certificate must pass CA verification (the default)

Optional (param=) passed conditionals may also be used to provide additional filtering on which certificates may or may not be used against the particular path. This is based on pattern matching against client certificate components. (UNNUMBERED) [CI:string] transaction cipher [IS:/record=string] specified Issuer (CA) DN record only [IS:string] entire Issuer (CA) DN [KS:integer] minimum key size [SU:/record=string] specified Subject (client) DN record only [SU:string] entire Subject (client) DN

These function and can be used in a similar fashion to mapping rule conditionals (see ([-.CONFIG]DOC_config.sdml) document, (Conditional Configuration) section). This includes the logical ORing, ANDing and negating of conditionals. Asterisk wildcards match any zero or more characters, percent characters any single character. Matching is case-insensitive.

Note that the (IS:) and (SU:) conditionals each have a (specific-record) and an (entire-field) mode. If the conditional string begins with a slash then it is considered to be a match against a specified record contents within the field. If it begins with a wildcard then it is matched against the entire field contents. Certificate DN records recognised by WASD, (SIMPLE) (/C=\BOLD) countryName (/ST=\BOLD) stateOrProvinceName (/SP=\BOLD) stateOrProvinceName (/L=\BOLD) localityName (/O=\BOLD) organizationName (/OU=\BOLD) organizationalUnitName (/CN=\BOLD) commonName (/T=\BOLD) title (/I=\BOLD) initials (/G=\BOLD) givenName (/S=\BOLD) surname (/D=\BOLD) description (/UID=\BOLD) uniqueIdentifier (/Email=\BOLD) pkcs9_emailAddress

The following (fairly contrived) examples provide an illustration of the basics of X509 conditionals. When matching against Issuer and Subject DNs some knowlege of their contents and structure is required (see (hd_ssl_ref) for some basic resources). [X509] # only give (VeriSign)ed ones access /controlled/path1/* r+w,param="[IS:/O=VeriSign\ Inc.]" # only give non-(VeriSign)ed ones access /controlled/path2/* r+w,param="[!IS:/O=VeriSign\ Inc.]" # only allow 128 bit keys using RC4-MD5 access /controlled/path3/* r+w,param="[KS:128][CI:RC4-MD5]" # only give a (Thawte)-signed client based in Australia # with the following email address access /controlled/path4/* r+w,param="\ [IS:*/O=Thawte\ Consulting\ cc/*]\ [SU:*/C=AU/*/Email=mark.daniel@wasd.vsm.com.au*]" # use the subject DN common-name record as the remote-user name # furthermore, restrict the CA's allowed to be used this way /VMS/* r+w,param="[RU:/CN=][IS:/O=WASD\ CA\ Cert]"

Of course, access control via group membership is also available. The (effective username) for the list is the 32 digit fingerprint of the client certificate (shown as REMOTE_USER IN the first example of (hd_ssl_x509_cgi)), or the Subject DN record as specified using the [RU:/(record)=] directive. This may be entered into simple lists as part of a group of which membership then controls access to the resource. The following examples show the contents of simple list files containing the X.509 fingerprints, derived remote-user names, and the required WASD_CONFIG_AUTH realm entries. # FINGERPRINTS.$HTL # (a file of X.509 fingerprints for access to "/path/requiring/cert/") 106C8342890A1703AAA517317B145BF7 mark.daniel@wasd.vsm.com.au 6ADA07108C20338ADDC3613D6D8B159D just.another@where.ever.com # CERT_CN.$HTL # (a file of X.509 remote-user names derived using [RU:/CN=] Mark_Daniel mark.daniel@wasd.vsm.com.au Just_Another just.another@where.ever.com [X509;FINGERPRINTS=list] /path/requiring/cert/* r+w [X509;CERT_CN=list] /path/requiring/cn/* r+w

In a similar fashion the effective username can be placed in an access restriction list. The following configuration would only allow the user of the certificate access to the specified resources. Other verified certificate holders would be denied access. [X509] /httpd/-/admin/* ~106C8342890A1703AAA517317B145BF7,r+w /wasd_root/local/* ~106C8342890A1703AAA517317B145BF7,r+w /other/path/* ~Mark_Daniel,r+w,param="[ru:/cn=]" /yet/another/path/* ~Just_Another,r+w,param="[ru:/cn=]" (Certificate Authority Verification File\hd_ssl_x509_cafile)

For the CA certificate component of the client certificate to be verified as being what it claims to be (and thus establishing the integrity of the client certificate) a list of such certificates must be provided for comparison purposes. For WASD this list is contained in a single, plain-text file variously specified using either the WASD_CONFIG_SSL_CAFILE logical or per-service ([ServiceSSLclientCAfile]) directives, or the global [SSLverifyPeerCAFile] directive.

Copies of CA certificates are available for such purposes. The PEM copies (base-64 encoded versions of the binary certificate) can be placed into this file using any desired text editor. Comments may be inserted by prefixing with the (#) character. For WASD this would be best stored in the WASD_ROOT:[LOCAL] directory, or site equivalent.

An example of how such a file appears is provided below (bulk of the file has been (8< snipped 8<) for bevity). ## ## Bundle of CA Root Certificates ## ## Certificate data from Mozilla as of: Wed Jan 18 04:12:05 2017 GMT ## ## This is a bundle of X.509 certificates of public Certificate Authorities ## (CA). These were automatically extracted from Mozilla's root certificates ## file (certdata.txt). This file can be found in the mozilla source tree: ## https://hg.mozilla.org/releases/mozilla-release/raw-file/default/security/nss/lib/ckfw/builtins/certdata.txt ## ## It contains the certificates in PEM format and therefore ## can be directly used with curl / libcurl / php_curl, or with ## an Apache+mod_ssl webserver for SSL client authentication. ## Just configure this file as the SSLCACertificateFile. ## ## Conversion done with mk-ca-bundle.pl version 1.27. ## SHA256: dffa79e6aa993f558e82884abf7bb54bf440ab66ee91d82a27a627f6f2a4ace4 ## GlobalSign Root CA ================== -----BEGIN CERTIFICATE----- MIIDdTCCAl2gAwIBAgILBAAAAAABFUtaw5QwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMCQkUx GTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNVBAMTEkds b2JhbFNpZ24gUm9vdCBDQTAeFw05ODA5MDExMjAwMDBaFw0yODAxMjgxMjAwMDBaMFcxCzAJBgNV BAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYD VQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDa DuaZjc6j40+Kfvvxi4Mla+pIH/EqsLmVEQS98GPR4mdmzxzdzxtIK+6NiY6arymAZavpxy0Sy6sc THAHoT0KMM0VjU/43dSMUBUc71DuxC73/OlS8pF94G3VNTCOXkNz8kHp1Wrjsok6Vjk4bwY8iGlb Kk3Fp1S4bInMm/k8yuX9ifUSPJJ4ltbcdG6TRGHRjcdGsnUOhugZitVtbNV4FpWi6cgKOOvyJBNP c1STE4U6G7weNLWLBYy5d4ux2x8gkasJU26Qzns3dLlwR5EiUWMWea6xrkEmCMgZK9FGqkjWZCrX gzT/LCrBbBlDSgeF59N89iFo7+ryUp9/k5DPAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUF AAOCAQEA1nPnfE920I2/7LqivjTFKDK1fPxsnCwrvQmeU79rXqoRSLblCKOzyj1hTdNGCbM+w6Dj Y1Ub8rrvrTnhQ7k4o+YviiY776BQVvnGCv04zcQLcFGUl5gE38NflNUVyRRBnMRddWQVDf9VMOyG j/8N7yy5Y0b2qvzfvGn9LhJIZJrglfCm7ymPAbEVtQwdpf5pLGkkeB6zpxxxYu7KyJesF12KwvhH hm4qxFYxldBniYUr+WymXUadDKqC5JlR3XC321Y9YeRq4VzW9v493kHMB65jUr9TU/Qr6cf9tveC X4XSQRjbgbMEHMUfpIBvFSDJ3gyICh3WZlXi/EjJKSZp4A== -----END CERTIFICATE----- ((8< snip 8<)) (URL/ON)

The WASD OpenSSL package provides an example CA verification file. The exact date and source can be found in the opening commentary of the file itself. The contents of this file easily can be pared down to the minimum certificates required for any given site.

The bundle may be refreshed at any time using any reliable source. The cURL project provides such a resource suitable for its own use, Apache mod_ssl and WASD. This is sourced from the root certificates used by the Mozilla Foundation for its Firefox product (and others). Mozilla uses a non-PEM format source which must be converted before use by WASD. The cURL site provides this already converted for use with its own utility and made available as a general resource. (SIMPLE) http://curl.haxx.se/ http://curl.haxx.se/docs/caextract.html (URL/OFF)

Download the bundle using a command-line tool as in this example $ curl -o ca-bundle_crt.txt https://curl.haxx.se/ca/cacert.pem or as a save-as dialogue click from your favourite browser and then a transfer onto the VMS system. (URL/ON) (SIMPLE) https://curl.haxx.se/ca/cacert.pem (URL/OFF) (--------------------------------------------------------------------) (X.509 Authorization CGI Variables\hd_ssl_x509_cgi)

CGI variables specific to client certificate authorization are always generated for use by scripts and SSI documents. These along with the general WASD authorization variables are shown in the example below. Note, that due to length of particular items some in this example are displayed wrapped. WWW_AUTH_ACCESS == "READ+WRITE" WWW_AUTH_GROUP == "" WWW_AUTH_REALM == "X509" WWW_AUTH_REALM_DESCRIPTION == "X509 Client Certs" WWW_AUTH_TYPE == "X509" WWW_AUTH_USER == "Mark Daniel, mark.daniel@wasd.vsm.com.au" WWW_AUTH_X509_CIPHER == "RC4-MD5" WWW_AUTH_X509_FINGERPRINT == "10:6C:83:42:89:0A:17:03:AA:A5:17:31:7B:14:5B:F7" WWW_AUTH_X509_ISSUER == "/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)98/CN=VeriSign Class 1 CA Individual Subscriber-Persona Not Validated" WWW_AUTH_X509_KEYSIZE == "128" WWW_AUTH_X509_SUBJECT == "/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=www.verisign.com/repository/RPA Incorp. by Ref.,LIAB.LTD(c)98/OU=Persona Not Validated/OU=Digital ID Class 1 - Netscape /CN=Mark Daniel/Email=mark.daniel@wasd.vsm.com.au" WWW_REMOTE_USER == "106C8342890A1703AAA517317B145BF7"

Other CGI variables optionally may be enabled using WASD_CONFIG_MAP mapping rules. See (hd_ssl_cgi). Specific client certificate variables providing the details of such certificates are available with SSLCGI=apache_mod_ssl. These are of course in addition to the more general apache_mod_ssl variables described in the above section. Note that where some ASN.1 records are duplicated (as in SSL_CLIENT_S_DN) some variables will contain newline characters (0x10) between those elements (e.g. SSL_CLIENT_S_DN_OU). The line breaks in this example do not necesarily reflect those characters. WWW_SSL_CLIENT_A_KEY == "rsaEncryption" WWW_SSL_CLIENT_A_SIG == "md5WithRSAEncryption" WWW_SSL_CLIENT_I_DN == "/O=VeriSign, Inc./OU=VeriSign Trust Network /OU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)98 /CN=VeriSign Class 1 CA Individual Subscriber-Persona Not Validated" WWW_SSL_CLIENT_I_DN_CN == "VeriSign Class 1 CA Individual Subscriber-Persona Not Validated" WWW_SSL_CLIENT_I_DN_O == "VeriSign, Inc." WWW_SSL_CLIENT_I_DN_OU == "VeriSign Trust Network www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)98" WWW_SSL_CLIENT_M_SERIAL == "0BF233D4FE232A90F3F98B2CE0D7DADA" WWW_SSL_CLIENT_M_VERSION == "3" WWW_SSL_CLIENT_S_DN == "/O=VeriSign, Inc./OU=VeriSign Trust Network /OU=www.verisign.com/repository/RPA Incorp. by Ref.,LIAB.LTD(c)98 /OU=Persona Not Validated/OU=Digital ID Class 1 - Netscape /CN=Mark Daniel/Email=mark.daniel@wasd.vsm.com.au" WWW_SSL_CLIENT_S_DN_CN == "Mark Daniel" WWW_SSL_CLIENT_S_DN_EMAIL == "mark.daniel@wasd.vsm.com.au" WWW_SSL_CLIENT_S_DN_O == "VeriSign, Inc." WWW_SSL_CLIENT_S_DN_OU == "VeriSign Trust Network www.verisign.com/repository/RPA Incorp. by Ref.,LIAB.LTD(c)98 Persona Not Validated.Digital ID Class 1 - Netscape" WWW_SSL_CLIENT_V_END == "Feb 10 23:59:59 2001 GMT" WWW_SSL_CLIENT_V_START == "Dec 12 00:00:00 2000 GMT" (--------------------------------------------------------------------) (Certificate Management\hd_ssl_cert)

This is not a tutorial on X.509 certificates and their management. Refer to the listed references, (hd_ssl_ref), for further information on this aspect. It does provide some basic guidelines.

Certificates identify something or someone, associating a public cryptographic key with the identity of the certificate holder. It includes a distinguished name, identification and signature of the certificate authority (CA, the issuer and guarantor of the certificate), and the period for which the certificate is valid, possibly with other, additional information.

The three types of certificates of interest here should not be confused. (UNNUMBERED) (CA - \BOLD) The Certificate Authority identifies the (authority), or organization, that issues a certificate. (Server - \BOLD) Identifies a particular end-service. Its value as an guarantee of identity is founded in the (authority) of the organization that issues the certificate. It is the certificate specified to the server at startup. (Client - \BOLD) Identifies a particular client to a server via SSL (client authentication). Typically, the identity of the client is assumed to be the same as the identity of a human being. Again, its value as an guarantee of identity is founded in the (authority) of the organization that issues the certificate.

The various OpenSSL tools are available for management of all of these certificate types in each of the three SSL environments. (UNNUMBERED) The HP SSL1 for OpenVMS product provides the (SSL Certificate Tool) procedure can be used to perform most required certificate management tasks from a menu-driven interface (HP SSL1 V1.0-2C example). $ @SSL1$COM:SSL1$CERT_TOOL.COM (SSL Certificate Tool\BOLD) (Main Menu\BOLD) 1. View a Certificate 2. View a Certificate Signing Request 3. Create a Certificate Signing Request 4. Create a Self-Signed Certificate 5. Create a CA (Certification Authority) Certificate 6. Sign a Certificate Signing Request 7. Revoke a Certificate 8. Create a Certificate Revocation List 9. Hash Certificates 10. Hash Certificate Revocations 11. Exit Enter Option: The standard OpenSSL toolkit provides a number of command-line tools for creation and management of X.509 certificates. Or if you prefer something a little less arcane than the (ever so useful) command-line (not really an endorsement but)

XCA is a (GUI application\BOLD) intended for creating and managing X.509 certificates, certificate requests, RSA, DSA and EC private keys, Smartcards and CRLs. It uses the OpenSSL library for the cryptographic operations. The application is available for Linux, macOS and Windows, as well as source code. (....................................................................) (HTML=

https://hohnstaedt.de/xca
https://sourceforge.net/projects/xca/