-1

I have a Linux Apache web server running ownCloud set up. I wish to use a dynamic DNS service (such as No-IP Free) with this server because my public IP address is not static. I also wish to use a self-signed certificate (I know of the risks) with the server. When generating a self-signed certificate using OpenSSL via the command line, it asks me for the 'Fully Qualified Domain Name' of the server. I do not have a domain name. What should I enter into this field: the static local network IP of the server (e.g. 192.168.1.5); the dynamic public IP (e.g. 192.0.2.1) of my router (I will forward the port); or the dynamic DNS domain name that I will use (e.g. myserver.ddns.net)?

sebix
  • 4,175
  • 2
  • 25
  • 45
Robert
  • 1
  • 1

3 Answers3

1

The common name or CN is the domain name, which you enter into the URL-bar of your browser. It's the name, you use to refer to the server/website/service and the browser or any other client will compare these two values for verification. In your example, it will be myserver.ddns.net.

If you wish to use owncloud-setup via the IP (which is not the case here), you want to give the IP as common name.

Also, if you want to be able to access the setup via the domain and the (local) IP, you can use Subject Alternative Name/ SubjectAltName (SAN). This can be useful, if you want to access it without internet access, because it's hosted in the local network (and it's faster, as the data only travels inside your network, otherwise, it goes through out through your modem and comes back again).

sebix
  • 4,175
  • 2
  • 25
  • 45
0

The CN must be the exact domain you want to secure, if you had a static IP address, you could secure this one and fill by an IP address.

Unfortunately you do not have one and you had to use a dynamic DNS service to resolve your IP even if it changes.

In that case, you have to fill the CSR with: myserver.ddns.net because it's the url you'll use to access your app.

Do SSL Certificates work with dynamic IP addresses?

Yes. SSL Certificates are associated with the server and Common Name, not the IP address, so you may use SSL Certificates with our Dyn Standard DNS service and a dynamic IP address without a problem.

Source

Nabil Bourenane
  • 755
  • 4
  • 11
  • While a [FQDN](http://serverfault.com/q/609188/217116) can't be an IP address, the common name (CN) *can* be an IP address. – sebix Apr 03 '15 at 20:21
  • It cannot be in that case: 'The Common Name is typically composed of Host + Domain Name and will look like "www.yoursite.com" or "yoursite.com"'. Source : http://info.ssl.com/article.aspx?id=10048 – Nabil Bourenane Apr 03 '15 at 20:40
  • The page you linked does not mention ip addresses. See for example the answer on [Can an IP Address be used as the FQDN when requesting a SSL Certificate?](http://serverfault.com/a/503948/217116) here on SF, quoting also the defining RFC. – sebix Apr 03 '15 at 20:47
  • An IP Address can be used but what is the point of talking about Dynamic DNS "in that case" then ? You actually want to access your app with a dyndns domain because you have a dynamic ip address, you have to fill the CSR with the correct information. – Nabil Bourenane Apr 03 '15 at 21:04
  • Yes, but that wasn't the point I addressed. You wrote, that the CN can't be an IP, but that's not true, and you already fixed that. – sebix Apr 04 '15 at 08:47
  • I wrote an FQDN cannot be an address, it was a specific answer related to the fact that he has an dynamic IP address then it was obvious that he would access his app through his domain name that's why I said in commentary "in that case" but nevermind, I edited to be less confusing and help him but no problem I understood your point of view. – Nabil Bourenane Apr 04 '15 at 09:21
0

I do not have a domain name

Yes you do, the one attributed by the dynamic DNS service.

You probably will have to generate a root certificate authority, for which the FQDN (or common name) can be just what you want, and then generate a certificate for your webserver for which the FQDN will be the one given by the dynamic DNS provider.

The certificate you'll add to Apache must be configured with the FQDN you'll use to access the server, ie you won't be able to https://192.168.1.1 if the certficate FQDN is me.no-ip.com.

To go deeper into SSL cert management, I'll recommand this excellent howto

  • The OP talked about a self-signed certificate, why do you mention, the OP has probably to set up his own CA? What do you mean with this: *you won't be able to https://192.168.1.1*? – sebix Apr 03 '15 at 20:23