ca.framework.cert.management.custom.san and "cloudstack-setup-databases -i" force a single string which must be a hostname
- 主要言語
- Java
- スター
- 3.1k
- フォーク
- 1.4k
- 平均マージ
- 6日 19時間
- マージ済み PR(30日)
- 32
説明
### problem
I need to add 127.0.0.1 to the certificate for $IP:9090/ and ca.framework.cert.management.custom.san is the way to do it, but the feature interprets the entry as a single string, such that the following value:
_cloudstack.internal, 127.0.0.1_
leads to this kind of alt name configuration:
_~# openssl s_client -connect 127.0.01:9090 /dev/null | openssl x509 -noout -text | grep DNS:
IP Address:192.168.0.123, DNS:**cloudstack.internal, 127.0.0.1**_
Note that "cloudstack.internal, 127.0.0.1" is a single string here, so the comma separation is not a thing as I assumed.
Replacing cloudstack.internal with 127.0.0.1 takes me one step further, in that 127.0.0.1 is added to the alt names, but is treated as a hostname, not an IP.
_~#openssl s_client -connect 127.0.01:9090 /dev/null | openssl x509 -noout -text | grep DNS:
IP Address:192.168.0.123, DNS:127.0.0.1_
To further aggravate me, even _cloudstack-setup-databases -i 127.0.0.1_ produces the same results, 127.0.0.1 is treated as hostname, not IP, just like the above.
### versions
4.21.0.0 KVM
### The steps to reproduce the bug
_No response_
### What to do about it?
_No response_
コントリビューションガイド
調査の方向性
報告された 4.21.0.0 KVM セットアップで、ca.framework.cert.management.custom.san と cloudstack-setup-databases -i 127.0.0.1 を使って、まず証明書の動作を再現します。示されているとおりに openssl s_client と openssl x509 で証明書を検査します。SAN 値が正しく解析され、IP アドレスがホスト名ではなく IP エントリとして表現され、複数の値が個別に処理されれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 領域
- cloud, infrastructure, security
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 35/100