My azure VM was generated by someone else. It has become of importance. I need to create a server certificate for Database SSL. I am using certbot with letsencrypt as shown here:
https://www.vultr.com/docs/use-ssl-encryption-with-postgresql-on-ubuntu-20-04/
I come unstuck here in this step :
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
So, I have not put in a domain name because there does not seem to be one.
The hosts file is untouched:
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
There appears to be nothing with regards to a domain name at all:
root@zz-ubuntu1:~/tmp_certbot_key# hostname -f
ZZ-UBUNTU1
In order for the CA certificate to be generated by certbot as per the instructions I believe I need to give it an FQDN but maybe there is some dummy entry or fudge I can do...?
I have no access to the azure portal. I do have root.
Does anyone know if there are any steps I can take to generate the certificate? Preferably without doing any damage to the standalone Postgres DB that is on there.
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:
you can sign a certificate with a non-public CA key. Keep the CA key somewhere safe, provide the CA cert to the client and the signed cert and key to the postgres server. The public won't trust the certificate, but they're not connecting to the postgres server anyway. If the CA key is secure, this is cryptographically as secure as a publicly signed certificate. This is only an appropriate solution if the certificate need not be validated by the public, who would have no reason to trust your CA certificate.
as a similar alternative, you can use a self-signed certificate. This means that the key associated with the certificate is also the key used to sign the CSR, so the CA key materials and the server key materials are the same. You can then specify the self-signed certificate as the 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.
you can use a FQDN under a domain your organization controls. Your organization would have to allow you to update DNS or handle public http requests to the FQDN so that you can provide proof of ownership. For example, if you had example.com, you could get a publicly signed certificate for db.internal.example.com. Then you could define db.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.