BearSSL

Data Fields
br_ssl_server_choices Struct Reference

Type for the server policy choices, taken after analysis of the client message (ClientHello). More...

`#include <bearssl_ssl.h>`

## Data Fields
uint16_t | cipher_suite
| Cipher suite to use with that client. More...
unsigned | algo_id
| Hash function or algorithm for signing the ServerKeyExchange. More...
const br_x509_certificate * | chain
| Certificate chain to send to the client. More...
size_t | chain_len
| Certificate chain length (number of certificates). More...

## Detailed Description

Type for the server policy choices, taken after analysis of the client message (ClientHello).

## Field Documentation

## ◆ algo_id

unsigned br_ssl_server_choices::algo_id

Hash function or algorithm for signing the ServerKeyExchange.

This parameter is ignored for `TLS_RSA_*` and `TLS_ECDH_*` cipher suites; it is used only for `TLS_ECDHE_*` suites, in which the server signs the ephemeral EC Diffie-Hellman parameters sent to the client.

This identifier must be one of the following values:

- `0xFF00 + id`, where `id` is a hash function identifier (0 for MD5+SHA-1, or 2 to 6 for one of the SHA functions);
- a full 16-bit identifier, lower than `0xFF00`.

If the first option is used, then the SSL engine will compute the hash of the data that is to be signed, with the designated hash function. The `do_sign()` method will be invoked with that hash value provided in the the `data` buffer.

If the second option is used, then the SSL engine will NOT compute a hash on the data; instead, it will provide the to-be-signed data itself in `data`, i.e. the concatenation of the client random, server random, and encoded ECDH parameters. Furthermore, with TLS-1.2 and later, the 16-bit identifier will be used "as is" in the protocol, in the SignatureAndHashAlgorithm; for instance, `0x0401` stands for RSA PKCS#1 v1.5 signature (the `01`) with SHA-256 as hash function (the `04`).

Take care that with TLS 1.0 and 1.1, the hash function is constrainted by the protocol: RSA signature must use MD5+SHA-1 (so use `0xFF00`), while ECDSA must use SHA-1 (`0xFF02`). Since TLS 1.0 and 1.1 don't include a SignatureAndHashAlgorithm field in their ServerKeyExchange messages, any value below `0xFF00` will be usable to send the raw ServerKeyExchange data to the `do_sign()` callback, but that callback must still follow the protocol requirements when generating the signature.

## ◆ chain

const br_x509_certificate* br_ssl_server_choices::chain

Certificate chain to send to the client.

This is an array of `br_x509_certificate` objects, each normally containing a DER-encoded certificate. The server code does not try to decode these elements.

## ◆ chain_len

size_t br_ssl_server_choices::chain_len

Certificate chain length (number of certificates).

## ◆ cipher_suite

uint16_t br_ssl_server_choices::cipher_suite

Cipher suite to use with that client.

The documentation for this struct was generated from the following file:

- bearssl_ssl.h