1

My client has an Ubuntu server hosted by Digital Ocean. The server has no domain name, we access it via the public IP address. They want to start using https and provided me with a SSL certificate from GoDaddy.com. I need to provide GoDaddy with a CSR to set up the SSL certificate.

My attempt to create a CSR and private key on the server:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365

The problem is I have nothing to put for the Common Name (eg, fully qualified host name) []: prompt. Is it ok to simply put the IP address instead?

While researching this, I have come across Subject Alternative Names (SAN) that can specify IP addresses, but I'm not sure how to add that to the CSR.

Do I need to tell my client they should get a domain name?

JorgeZapatero
  • 13
  • 1
  • 4
  • This post is about adding SANs so I will experiment with that: https://stackoverflow.com/questions/43665243/invalid-self-signed-ssl-cert-subject-alternative-name-missing/43665244#43665244 – JorgeZapatero Dec 06 '19 at 21:25
  • Worth noting that the CN of certificate can be an address that resolves locally only. Host table entries or a local internal DNS server could be used to resolve the myserver.corp.com address used in the certificate. External CAs however may not issue a certificate for a domain you don't own however. – duct_tape_coder Dec 16 '19 at 22:29

1 Answers1

1

You can, but you shouldn't as you are obviously discussing DV-certificates here.

A certificate identify "something". That something can be an organization, an individual, a website, an email address, an IP address, a piece of code, etc.

If you are creating certificates to be used in the HTTPS world you need to have a DNS name in the certificate, in the SAN section. You should not use HTTPS URLs with IP addresses in the hostname part because, even if can technically work, and you can have certificates with IP addresses instead of names, they have to be generated differently and you will have far more troubles finding a CA to sign them.

You should register a domain name, anyone, and then use that as a suffix to name all your hosts, and you solve your problem they way it should be done: all hosts now have a name, and hence you can create a proper certificate for that name.

Patrick Mevzek
  • 9,921
  • 7
  • 32
  • 43
  • An IP address is usually pretty fluid as well. It would be much better for long term purposes to use DNS so that the service can be migrated to a different server. If necessary a dynamic DNS service could be used as well such as noip.com though this is a less professional approach. – duct_tape_coder Dec 16 '19 at 22:31
  • @duct_tape_coder IP addresses in https URLs are not a good idea. Hence you need to use hostnames, hence you need a certificate covering a name, not an IP. While technically, yes you can have certificates for IP addresses, but they will be far more difficult to get from a public CA. – Patrick Mevzek Dec 17 '19 at 09:12
  • We are agreeing. I should have said 'an IP address is too fluid'. – duct_tape_coder Dec 18 '19 at 20:24