| commit | a82207087d79c4dd85447bdacfd4de91be4e7166 | [log] [tgz] |
|---|---|---|
| author | Alan Kuo <Alan_Kuo@quantatw.com> | Thu Nov 26 11:15:29 2020 +0800 |
| committer | Ed Tanous <ed@tanous.net> | Sat Dec 12 01:46:28 2020 +0000 |
| tree | e452ce36b3df5889bafeae2f163a7f599c02d398 | |
| parent | 9e319cf0c5ee714cdd879a1d2a6e5b5ac96c7f1d [diff] |
Add hostname listener for generating self-signed HTTPS certificate
- Add a hostname listener that will create a self-signed HTTPS
certificate with the appropriate subject when the BMC gets its
hostname assigned via IPMI. The "insecure-disable-ssl" must be
disabled for this feature to take effect.
Note:
- New self-signed certificate subject: C=US, O=OpenBMC, CN=${hostname}
- If the same hostname is assigned, it will not be triggered
- Only the self-signed certificate with Netscape Comment of
"Generated from OpenBMC service" will be replaced
Details about certificate key usage:
- NID_basic_constraints
The CA boolean indicates whether the certified public key may be
used to verify certificate signatures.
Refer to: https://tools.ietf.org/html/rfc5280#section-4.2.1.9
- NID_subject_alt_name
Although the use of the Common Name is existing practice, it is
deprecated and Certification Authorities are encouraged to use the
dNSName instead.
Refer to: https://tools.ietf.org/html/rfc2818#section-3.1
- NID_subject_key_identifier
The subject key identifier extension provides a means of
identifying certificates that contain a particular public key.
Refer to: https://tools.ietf.org/html/rfc5280#section-4.2.1.2
- NID_authority_key_identifier
The authority key identifier extension provides a means of
identifying the public key corresponding to the private key used
to sign a certificate.
Refer to: https://tools.ietf.org/html/rfc5280#section-4.2.1.1
- NID_key_usage
- NID_ext_key_usage
id-kp-serverAuth
-- TLS WWW server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement
Refer to: https://tools.ietf.org/html/rfc5280#section-4.2.1.3
Refer to: https://tools.ietf.org/html/rfc5280#section-4.2.1.12
Tested:
- To test and verify the service is functionally working correctly,
we can use `openssl` and `ipmitool` to execute the following
commands:
- Assign BMC hostname
ipmitool -H $IP -I lanplus -U root -P 0penBmc -C 17 dcmi
set_mc_id_string $hostname
- Get BMC server certificate infomation
echo quit | openssl s_client -showcerts -servername $IP -connect
$IP:443
Signed-off-by: Alan Kuo <Alan_Kuo@quantatw.com>
Change-Id: I24aeb4d2fb46ff5f0cc1c6aa65984f46b0e1d3e2
This component attempts to be a "do everything" embedded webserver for openbmc.
At this time, the webserver implements a few interfaces:
BMCWeb is configured by setting -D flags that correspond to options in bmcweb/meson_options.txt and then compiling. For example, meson <builddir> -Dkvm=disabled ... followed by ninja in build directory. The option names become C++ preprocessor symbols that control which code is compiled into the program.
meson builddir ninja -C builddir
meson builddir -Dbuildtype=minsize -Db_lto=true -Dtests=disabled ninja -C buildir
If any of the dependencies are not found on the host system during configuration, meson automatically gets them via its wrap dependencies mentioned in bmcweb/subprojects.
meson builddir -Dwrap_mode=nofallback ninja -C builddir
meson builddir -Db_coverage=true -Dtests=enabled ninja coverage -C builddir test
When BMCWeb starts running, it reads persistent configuration data (such as UUID and session data) from a local file. If this is not usable, it generates a new configuration.
When BMCWeb SSL support is enabled and a usable certificate is not found, it will generate a self-sign a certificate before launching the server. The keys are generated by the secp384r1 algorithm. The certificate
C=US, O=OpenBMC, CN=testhost,SHA-256 algorithm.