If this is a private webserver, not on the public domain, why do you want a public SSL cert rather than a self signed cert ?
Is your server available (through the port forwarding ) on port 80 or 443 ? You would need a public domain name though, and public DNS - it’s can’t be done on a private domain name.
With a public domain name, you could also use the DNS-01 challenge which doesn’t need access via port 80 or 443.
The server is private but mainly accessed from remote/outside the private network.
I found references on let’s encrypt on a tutorial to build a cloud server again namely available from remote via port forwarding and this is why I’m here
By the time I’m writing this post I’m also working on a self signed cert
for port forwarding I can’t use 80 (router issue) and I can use 443
if you have a relatively standard apache setup ( or you could use standalone method, but you would need to stop your current apache server for that ) .
That info is fine - as long as you don’t have a control panel, and you have the each virtual host file for each domain (rather than one file containing all the virtual hosts).
The command earlier should work, alternatively you can use a DNS challenge (which requires you to add a given token into your DNS, rather than via https on port 443).
@serverco:
quick question: I’ve set up a self signed cert which I can see to work when I connect to the server via ssh and brows with lynx.
When I connect remotely via browser, the apache server redirect from http://my_server.no-ip.com:xxx/virtual_host -> https://local_domain.com/virtual_host which doesn’t work obviously
I don’t know if this will happen also with the option u gave me. If yes, do you know if there is a way not to redirect the site?
when you say “local_domain.com” is this a public domain name that you have registered and own ? or is this just a local domain name you have created yourself ?
Let’s Encypt will only issue certificates for public domain names that it can verify.
with http://my_server.no-ip.com:xxx it sounds like you have a URL redirect set up, rather than DNS pointing to your domain name, which won’t easily work in this setup (although you are only redirecting http not https so should be OK).
Personally I’d set up dynamic DNS (I’m assuming you aren’t on a static IP) for your domain name. You do need a real domain name though ( which you can always get for free if that’s an issue). Then you will no longer have the redirect
local_domain.com: il mio hostname in locale (intranet, home server linux which I’m setting up)
http://my_server.no-ip.com:xxx: no-ip.com offer a free dynamic DNS name like dyn.com or openDNS.com. This is the address of my private webserver from outside the intranet, remote access
virtual_host: this will be the name of the forum or cloud as specified in the virtual_hosts file of apache
in other terms, if: forum.no-ip.com is the dynamic dns name provided by no-ip.com
8100 port to forward to my webserver (intranet, home webserver)
forum is the web site as installed using virtual_hosts in apache2
to access the forum from outside the intranet I’ll write on the browser addtress: forum.no-ip.com:8100/forum
http://…: I need to verify if the free service allow an https connection (make it sense as question?!)
From what you said above this redirects to “https://local_domain.com/virtual_host” does it redirect so that’s what you see in the browser ? or does the browser still show “http://my_server.no-ip.com:xxx” ?
sorry for my absence. I stopped checking let’s encrypt now for some time untill I’ll have a new modem/router which will allow to use 443 incoming port
I’m also trying to figure out where this problem is part of web server configuration or DNS config.
I don-t know if the next question has a simple answer. if not I’ll work it out.
The question: no-ip.com configure a dynamic DNS service to find my server (in this case forum.no-ip.com) but I don’t owe the address (no FQDN, I think) nor I have access to this configuration. can I still use let’s encrypt or I need a FQDN for it?
I think the no-ip.com names are FQDNs (they're publicly-resolvable unique names, right?). Do you somehow share that name with someone else? Do you only have use of particular forwarded ports on that host or something?
The problem you might have with their service is that if they don't have a rate limit exemption, lots of people will be trying to get certs under that domain and will tend to hit a Let's Encrypt rate limit.