self-signed certificated used after https is enabled requires a Subject Alt Name
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
StarlingX |
Fix Released
|
High
|
Teresa Ho |
Bug Description
Brief Description
-----------------
When the system is first configured to enable https a self-signed certificate is installed temporarily, and then the public openstack endpoint URLs are updated to use HTTPS rather than HTTP. The self-signed certificate is valid only for CN=*wrs.com and so a remote user must disable SSL/TLS verification in order to make subsequent HTTPS requests to that URL until it can install a proper certificate. Disabling verification defeats the purpose of having a certificate installed in the first place.
A typical error from this scenario is as such (from a Go HTTP client):
"Post https:/
Another example, from wget:
[wrsroot@
--2019-05-01 14:54:35-- https:/
Connecting to 10.10.10.2:5000... connected.
ERROR: cannot verify 10.10.10.2's certificate, issued by ‘/C=CA/
Self-signed certificate encountered.
ERROR: certificate common name ‘*.wrs.com’ doesn't match requested host name ‘10.10.10.2’.
To connect to 10.10.10.2 insecurely, use `--no-check-
My opinion, is that the self-signed certificate being used should set the CN to the OAM floating IP address, or include the OAM floating IP in the list of valid Subject Alt Names, or both.
Severity
--------
Critical, this prevents a remote API user from transitioning from HTTP to HTTPS, without disabling TLS/SSL verification.
Steps to Reproduce
------------------
From a remote CLI client,
1) cp /etc/platform/
2) modify openrc-public to change the URL from 192.168.204.2 to 10.10.10.2, and the endpoint/interface references from "internal" to "public"
3) source /home/wrsroot/
4) enable https "system modify --https_
5) modify openrc-public to set the URL scheme to HTTPS
6) source /home/wrsroot/
7) make any other system command access (i.e., system show)
8) observe an error similar to the ones listed in the description (see above)
Expected Behavior
------------------
The SSL/TLS verification should succeed.
Actual Behavior
----------------
The SSL/TLS verification fails because the certificate does not contain a proper CN or Subject Alt Name.
Reproducibility
---------------
100%
System Configuration
-------
Any
Branch/Pull Time/Commit
-------
2019-04-24
Last Pass
---------
Unknown
Timestamp/Logs
--------------
See above
Test Activity
-------------
Developer Testing.
tags: | added: stx.config |
Changed in starlingx: | |
status: | Triaged → In Progress |
Marking stx.2.0 release gating as https functionality is a release requirement.