apache / apache/cloudstack

ca.framework.cert.management.custom.san and "cloudstack-setup-databases -i" force a single string which must be a hostname

未關閉
#11,848 1 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視
no-issue-activity
主要語言
Java
星號
3.1k
分支
1.4k
平均合併
6 天 19 小時
30 天內合併 PR
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

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。