我的Azure VM是由其他人生成的。它已经变得非常重要。我需要为数据库SSL创建服务器证书。我正在使用certbot和letsENCRYPT,如下所示:
https://www.vultr.com/docs/use-ssl-encryption-with-postgresql-on-ubuntu-20-04/
在这一步中,我陷入了困境:
sudo certbot certonly --standalone -d zz-ubuntu1
Account registered.
Requesting a certificate for zz-ubuntu1
An unexpected error occurred:
Error creating new order :: Cannot issue for "zz-ubuntu1": Domain name needs at least one dot
所以,我没有放入域名,因为似乎没有一个。
主机文件保持不变:
127.0.0.1 localhost
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
域名似乎与此毫无关系:
root@zz-ubuntu1:~/tmp_certbot_key# hostname -f
ZZ-UBUNTU1
为了让certbot按照说明生成CA证书,我认为我需要给它一个FQDN,但可能有一些虚拟条目或捏造我可以做...?
我无法访问蔚蓝门户网站。我确实有根。
有没有人知道我可以采取什么步骤来生成证书?最好不要对那里的独立Postgres数据库造成任何损害。
1条答案
按热度按时间wsxa1bj11#
Let's encrypt is a way to obtain publicly signed certificates. That means the certificate signing authority must have some way of verifying that the domain in the Cert signing request can be associated with the request. Generally that's done by either adding a public DNS CNAME or TXT record with the content that "proves" you own the domain, or by adding content to a web endpoint on the domain, which achieves the same evidence that you own the domain.
As an unqualified hostname, nobody owns
ZZ-UBUNTU1
. it's merely a string identifier. You can't get a public certificate for this name because there would be no way to verify it before signing.Here's some things you can do:
ca-cert
in your client config so the key can be verified. This also is only valid for privately used certificates, as the public would have no way to verify authenticity.example.com
, you could get a publicly signed certificate fordb.internal.example.com
. Then you could definedb.internal.example.com
to be 127.0.0.1 or whatever IP in /etc/hosts. you should be aware that any FQDN with a publicly signed certificate can be discovered in the Certificate transparency logs. Further, public DNS may not reliably resolve to 127.0.0.1 or other private addresses due to security considerations, but that's more likely on home networks than in azure.Let's Encrypt certificates are good for 90 days. The article says to restart postgres to pick up the new certificates, but this heavy-handed approach will interrupt postgresql service while the restart happens. As of postgres 10 which was some time ago, ssl certs can be reloaded without restarting the server or interrupting existing clients. So if you do end up using let's encrypt, instead of restarting your db server every 10 days and causing an outage, issue a reload instead.