118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
|
socket, but must provide bi-directional flow. Also
setting session parameters for SSL handshake.</dd>
<blockquote>
<dl>
<dt><strong>-alpn</strong> <em>list</em></dt>
<dd>List of protocols to offer during Application-Layer
Protocol Negotiation (ALPN). For example: h2, http/1.1, etc.</dd>
<dt><strong>-cadir</strong> <em>dir</em></dt>
<dd>Set the CA certificates path. The default directory is platform
specific and can be set at compile time. This can be overridden
via the <b>SSL_CERT_DIR</b> environment variable.</dd>
<dt><strong>-cafile </strong><em>filename</em></dt>
<dd>Set the certificate authority (CA) certificates file. The default
is the cert.pem file in the OpsnSSL directory. This can also be
|
|
>
|
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
|
socket, but must provide bi-directional flow. Also
setting session parameters for SSL handshake.</dd>
<blockquote>
<dl>
<dt><strong>-alpn</strong> <em>list</em></dt>
<dd>List of protocols to offer during Application-Layer
Protocol Negotiation (ALPN). For example: <em>h2</em> and
<em>http/1.1</em>, but not <em>h3</em> or <em>quic</em>.</dd>
<dt><strong>-cadir</strong> <em>dir</em></dt>
<dd>Set the CA certificates path. The default directory is platform
specific and can be set at compile time. This can be overridden
via the <b>SSL_CERT_DIR</b> environment variable.</dd>
<dt><strong>-cafile </strong><em>filename</em></dt>
<dd>Set the certificate authority (CA) certificates file. The default
is the cert.pem file in the OpsnSSL directory. This can also be
|
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
|
<p>
As indicated above, individual channels can be given their own callbacks
to handle intermediate processing by the OpenSSL library, using the
<strong>-command</strong>, <strong>-password</strong>, and
<strong>-validate_command</strong> options passed to either of
<strong>tls::socket</strong> or <strong>tls::import</strong>.
</p>
<blockquote>
<dl>
<dt><strong>-command</strong> <em>callback</em></dt>
<dd>
Invokes the specified <em>callback</em> script at
several points during the OpenSSL handshake.
Values returned from the callback are ignored.
Arguments appended to the script upon callback take one of the
following forms:
<br>
<br>
<dl>
<dt>
|
>
>
|
|
|
|
<
|
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
|
<p>
As indicated above, individual channels can be given their own callbacks
to handle intermediate processing by the OpenSSL library, using the
<strong>-command</strong>, <strong>-password</strong>, and
<strong>-validate_command</strong> options passed to either of
<strong>tls::socket</strong> or <strong>tls::import</strong>.
If the callback generates an error, the <b>bgerror</b> command with be
invoked with the error information.
</p>
<blockquote>
<dl>
<dt><strong>-command</strong> <em>callback</em></dt>
<dd>
Invokes the specified <em>callback</em> script at several points
during the OpenSSL handshake and use. See below for the possible
arguments passed to the callback script. Values returned from the
callback are ignored.
<br>
<br>
<dl>
<dt>
|
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
|
<ul>
<li>Possible values for <em>major</em> are:
<code>handshake, alert, connect, accept</code>.</li>
<li>Possible values for <em>minor</em> are:
<code>start, done, read, write, loop, exit</code>.</li>
<li>The <em>message</em> argument is a descriptive string which may
be generated either by <code>SSL_state_string_long()</code> or by
<code>SSL_alert_desc_string_long()</code>, depending on context.</li>
<li>For alerts, the possible values for <em>type</em> are:
<code>warning, fatal, and unknown</code>. For others,
<code>info</code> is used.</li>
</ul>
</dd>
<dt>
|
|
|
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
|
<ul>
<li>Possible values for <em>major</em> are:
<code>handshake, alert, connect, accept</code>.</li>
<li>Possible values for <em>minor</em> are:
<code>start, done, read, write, loop, exit</code>.</li>
<li>The <em>message</em> argument is a descriptive string which may
be generated either by <code>SSL_state_string_long()</code> or by
<code>SSL_alert_desc_string_long()</code>, depending on the context.</li>
<li>For alerts, the possible values for <em>type</em> are:
<code>warning, fatal, and unknown</code>. For others,
<code>info</code> is used.</li>
</ul>
</dd>
<dt>
|
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
|
</dd>
<br>
<dt><strong>-password</strong> <em>callback</em></dt>
<dd>
Invokes the specified <em>callback</em> script when OpenSSL needs to
obtain a password. The callback should return the password as a string.
No arguments are appended to the script upon callback.
</dd>
<br>
<dt><strong>-validatecommand</strong> <em>callback</em></dt>
<dd>
Invokes the specified <em>callback</em> script during handshake in
order to validate the provided value(s).
To reject the value and abort connection, the callback should return 0.
To accept the value, it should return 1. To reject the value, but
continue the connection, it should return 2.
<br>
<br>
<dl>
<dt>
<strong>alpn</strong> <em>protocol</em>
</dt>
<dd>
For servers, this form of callback is invoked when the client ALPN
extension is received. Where <em>protocol</em> is the first
<b>-alpn</b> specified protocol common to the both the client and
server. If none, the first client specified protocol is used.
</dd>
<br>
<dt>
<strong>hello</strong> <em>servername</em>
</dt>
|
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
|
<
>
|
>
|
|
>
|
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
|
</dd>
<br>
<dt><strong>-password</strong> <em>callback</em></dt>
<dd>
Invokes the specified <em>callback</em> script when OpenSSL needs to
obtain a password. See below for the possible arguments passed to
the callback script. See below for valid return values.
<br>
<br>
<dl>
<dt>
<strong>password</strong> <em>rwflag size</em>
</dt>
<dd>
Invoked when loading or storing a PEM certificate with encryption.
Where <em>rwflag</em> is 0 for reading/decryption or 1 for
writing/encryption (can prompt user to confirm) and
<em>size</em> is the max password length in bytes.
The callback should return the password as a string.
</dd>
</dd>
<br>
<dt><strong>-validatecommand</strong> <em>callback</em></dt>
<dd>
Invokes the specified <em>callback</em> script during handshake in
order to validate the provided value(s). See below for the possible
arguments passed to the callback script.
To reject the value and abort connection, the callback should return 0.
To accept the value and continue the connection, it should return 1.
To reject the value, but continue the connection, it should return 2.
<br>
<br>
<dl>
<dt>
<strong>alpn</strong> <em>protocol</em>
</dt>
<dd>
For servers, this form of callback is invoked when the client ALPN
extension is received. Where <em>protocol</em> is the first
<b>-alpn</b> specified protocol common to the both the client and
server. If none, the first client specified protocol is used.
Called after hello and ALPN callbacks.
</dd>
<br>
<dt>
<strong>hello</strong> <em>servername</em>
</dt>
|