Diff

Differences From Artifact [cc4fe664cc]:

To Artifact [a0b037f824]:


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>