Jump to content
rix

[Request/Done] Let's Encrypt Container

577 posts in this topic Last Reply

Recommended Posts

That's fine. All certs are issued to one main address, and can have many alternative addresses. Letsencrypt script must have listed your owncloud subdomain first when it requested the cert from the server, so that became the main "issued to" address.

 

Attached are screenshots for yahoo's cert. When browsing local.yahoo.com, the cert says it is issued to search.yahoo.com. But when you look at the alternative names, you see both listed, among dozens of others.

 

As long as all the subdomains are listed, your cert will work on them and you'll get the padlock

Capture20.JPG.79db62f19da51b6ccfb48523eb938eb8.JPG

Capture21.JPG.ce02432840335374de1292a48870c6b1.JPG

Share this post


Link to post

anyone using this container along with linuxsever.io owncloud. their owncloud container uses ngix, mariadb and ssl.

 

I have lets encrypt working great with my two duckdns domains, when i type the address from the internet i get the landing page. been looking at the examples of the config files but when i modify mine it breaks. SO i am wondering if the use of there own ssl is causing the problem?

 

 

Share this post


Link to post

anyone using this container along with linuxsever.io owncloud. their owncloud container uses ngix, mariadb and ssl.

 

I have lets encrypt working great with my two duckdns domains, when i type the address from the internet i get the landing page. been looking at the examples of the config files but when i modify mine it breaks. SO i am wondering if the use of there own ssl is causing the problem?

I am using it, and have no issues, from inside or outside my network.

I have done NO change to the OwnCloud docker, so it still runs on port 443 with whatever cert they are using.

The docker itself runs on port 8000 and proxy passed through nginx like any other docker. No issues so far.

 

site-conf/default:

server {

listen 443 ssl;

server_name owncloud.domain.com;

location / {
	include /config/nginx/proxy.conf;
	proxy_pass https://<unraid_ip>:<oc-docker Port>/;
}

Share this post


Link to post

anyone using this container along with linuxsever.io owncloud. their owncloud container uses ngix, mariadb and ssl.

 

I have lets encrypt working great with my two duckdns domains, when i type the address from the internet i get the landing page. been looking at the examples of the config files but when i modify mine it breaks. SO i am wondering if the use of there own ssl is causing the problem?

I am using it, and have no issues, from inside or outside my network.

I have done NO change to the OwnCloud docker, so it still runs on port 443 with whatever cert they are using.

The docker itself runs on port 8000 and proxy passed through nginx like any other docker. No issues so far.

 

site-conf/default:

server {

listen 443 ssl;

server_name owncloud.domain.com;

location / {
	include /config/nginx/proxy.conf;
	proxy_pass https://<unraid_ip>:<oc-docker Port>/;
}

 

Thank I will try that.

 

EDIT:

 

heck yeah this worked thanks

 

Share this post


Link to post

I cannot remember what thread this was posted on but someone else was having problems displaying the owcloud webpages from outside their network. and it was a easy fix to get to work.

 

 

can anyone point me in the right right direction.

Share this post


Link to post

This is how my Owncloud installation is working:

 

Nginx config:

server {
listen 80;
server_name cloud.DOMAIN.ch;

# tell users to go to SSL version this time
if ($ssl_protocol = "") {
rewrite     ^   https://$server_name$request_uri? permanent;
}
}

server {
listen 443 ssl;
server_name cloud.DOMAIN.ch;

# Add headers to serve security related headers
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options "SAMEORIGIN";
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag none;


# The internal IP of the VM that hosts your Apache config
set $upstream 192.168.178.200:8000;

location / {

proxy_pass_header Authorization;
proxy_pass http://$upstream;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_buffering off;
client_max_body_size 0;
proxy_read_timeout 36000s;
proxy_redirect off;

}
}

 

Owncloud config:

<?php
$CONFIG = array (
  'instanceid' => 'XXXXX',
  'passwordsalt' => 'tXXXXX',
  'secret' => 'XXXX',
  'trusted_domains' => 
  array (
    0 => '192.168.178.200:8000',
    1 => 'cloud.DOMAIN.ch',
  ),
  'datadirectory' => '/var/www/html/data',
  'overwrite.cli.url' => 'http://192.168.178.200:8000',
  'dbtype' => 'sqlite3',
  'version' => '9.0.2.2',
  'logtimezone' => 'UTC',
  'installed' => true,
  'trusted_proxies' => 
  array (
    0 => 
    array (
      0 => '192.168.178.200',
    ),
  ),
  'forwarded_for_headers' => 
  array (
    0 => 'HTTP_X_FORWARDED',
    1 => 'HTTP_FORWARDED_FOR',
  ),
);

 

 

Hope this works for you too

Share this post


Link to post

It's working but for me a really strange , i can get to the web portion but when i try to use a client to sync my devices I get an odd error.

 

see picture,

 

Status.php is not missing but its not because i can see it. See second picture

 

this for owncloud

owncloud.jpg.6ec760df406d4a53c469b6c21e148cc5.jpg

Share this post


Link to post

It's working but for me a really strange , i can get to the web portion but when i try to use a client to sync my devices I get an odd error.

 

see picture,

 

Status.php is not missing but its not because i can see it. See second picture

 

this for owncloud

 

second picture

status.PNG.d9c87fbbd7637a556bde8006b508c65a.PNG

Share this post


Link to post

Cant help you there as I'm not using the sync client, sorry!

Share this post


Link to post

Cant help you there as I'm not using the sync client, sorry!

 

no prob, at least you read and felt my pain (LOL)

Share this post


Link to post

I could never get it this to work but I will tell you what does work for me:

 

https://hub.docker.com/r/jwilder/nginx-proxy/

with

https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion

 

It's actually really cool..you add extra variables to your dockers and then restart everything.

 

I just ran the docker commands in the docker-letsencrypt-nginx-proxy-companion link for both containers from a shell prompt specifying my paths to create the containers and then added the variables like the domain info to the dockers and restarted it all.

 

now I have my couchpotato at movies.domain.com and sonarr at tv.domain.com, etc.

 

I never have to manually mess with the nginx config at all.

 

Share this post


Link to post

@RXWatcher,

 

I could never get it this to work but I will tell you what does work for me:

 

I#m feeling exactly like you. Never managed to setup that container correctly. Just today a friend explained that he uses the same jWilder-ngnix but without Unraid's Version  of Docker and instead with DockerCompose. I tried with his help to set it up myself but again failed. If you could find time to make a short step to step guide how you did it. It would be highly appreciated.

 

Thanks,

Matt

Share this post


Link to post

This works for UNRAID 6.2 only

 

1) Start by adding your domain records. My unraid runs out of my house and I have a dynamic IP address so I use the routers(netgear in this case) DDNS service. I setup my subdomains to use CNAMES that point to this DDNS address:

bUB1amw.png

 

2) SSH into the unraid server and run these in order, editing the host port(1969) and appdata path: /mnt/cache/docker/appdata/nginx/certs on both as needed. I just picked an unused port:

docker run -d -p 1969:80 -p 443:443 \
  --name nginx-proxy \
  -v /mnt/cache/docker/appdata/nginx/certs:/etc/nginx/certs:ro \
  -v /etc/nginx/vhost.d \
  -v /usr/share/nginx/html \
  -v /var/run/docker.sock:/tmp/docker.sock:ro \
  jwilder/nginx-proxy

docker run -d \
  --name nginx-proxy-companion-letsencrypt \
  -v /mnt/cache/docker/appdata/nginx/certs:/etc/nginx/certs:rw \
  --volumes-from nginx-proxy \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  jrcs/letsencrypt-nginx-proxy-companion

 

 

3) Edit each docker you want running through this and add some variables. I blurred out my information but it's movies.domain.com and my-email@gmail.com:

PANZHYJ.png

 

 

If your docker app normally uses SSL then you need to tell the nginx-proxy that by adding another variable. In this case, this is my owncloud:

zzoYGgf.png

 

4) I added two port forwards to my router. 192.168.1.10 is my internal IP of the unraid box:

SGR6I6W.png

 

 

5) Finally, I restart the app dockers and they should automatically register with the nginx-proxy and I should be able to hit them via http://subdomain.domain.com and it will auto redirect to https://subdomain.domain.com

 

 

Now anytime I add a new docker app that I want exposed, I just need to create the subdomain in the DNS and add the variables and boom, it's done.

 

 

I've done this with like 5 or 6 docker apps and its working great.

 

 

Keep the commands that you need to run from the shell though as I've had to drop those containers and re-run it. I think it was when I moved my appdata directory.

 

 

Share this post


Link to post

Great Tutorial! - thanks

 

I did it quite same. However I had to reset my appdata and docker image. After that I'm getting the message

 

Welcome to nginx!

If you see this page, the nginx web server is successfully installed and working. Further configuration is required.

For online documentation and support please refer to nginx.org.
Commercial support is available at nginx.com.

Thank you for using nginx.

 

after few seconds I get forwarded to the SSL-Port with the message of

 

503 Service Temporarily Unavailable

 

I guess there is some error with the download of the certificates, bc. if I look into my path of  /mnt/user/appdata/ngnix/certs - subfolders are created, they are just empty.

 

In the Log of proxy-ngnix the only "strange text" i get is:

[0m[0;33;1mdockergen.1 | [0;31;1m2016/06/14 21:00:50 Error running notify command: nginx -s reload, exit status 1

 

in the docker jrcs/letsencrypt-nginx-proxy-companion log it says

Sleep for 3600s
Creating/renewal subdomain1.domain.com certificates... (subdomain1.domain.com)
Creating/renewal subdomain2.domain.com certificates... (subdomain2.domain.com)
Sleep for 3600s

 

I guess I'm missing something with the letsencrypt certification, but somehow I can't figure it out yet. Any help / directions appreciated.

 

cheers & good night,

Matt

Share this post


Link to post

do you have your subdomains setup? It requires them to be in DNS first. I definitely have a fully populated certs directory.

 

I do believe the https issue its because you dont have certs being generated. Tthe extra variables are not correct(including email) or there is an issue with the DNS or I think somehow LE has to validate that you are infact the domain owner. I wonder if thats your issue:

https://letsencrypt.org/how-it-works/

 

 

An idea..open the router ports first so LE can talk to the webserver?!?

 

Share this post


Link to post

Okay found the issue. Cloudflare.

 

Now the certificates are created. However the forwarding still doesn't work.

I'll do a full reset on the docker image today and try again. But at least there is light at the end of the tunnel.

 

Edit - 16.06.2016 - 16:35

After removing CloudFlare (not only Pausing) the Account - the certificates got created. But still it wouldn't work with messages like:

  • 503 Service Temporarily Unavailable
  • 403 **
  • sub.domain.com denied the connection.
  • [0;36;1mnginx.1 | [0;31;1m2016/06/16 11:38:59 [error] 23#23: *16 directory index of "/usr/share/nginx/html/" is forbidden, client: XX.XX.XX.XX, server: localhost, request: "GET / HTTP/1.1", host: "domain.com"

 

I tried it with RXWatcher's Config, the one noted at Jamie Magee some pages before (that I somehow oversaw), reverted to the aptalca's one where at least the starting page worked, but no subdomains, until I read on the page of Jamie Magee in a commen that it might be an issue related to the docker version - so I went and without further thinking upgraded my tower to 6.2 beta - and it's just working like a charm

 

so for any other poor sucker who nearly twice thought about kicking the pc out of the windows - I recommend to get the update, disable his cloudflare account (at least for setup) and just input as RXWatcher or JamieMagee suggested. It's amazingly simple once you figured that out. :-)

 

and now I'm going to get some beer (maybe a lot)^^

Share this post


Link to post

Glad you got it working. I added a line in bold red that it only works on 6.2. I honestly hadnt tried it til I was on 6.2.

Share this post


Link to post

Renewal was up, but failed:

cronjob running at Sat Jun 18 02:00:01 CEST 2016
Updating certbot script. It will display help info, which you can ignore

[...]

URL is XXXX.XX
Subdomains are
deciding whether to renew the cert(s)
Preparing to renew certificate that is older than 60 days
Temporarily stopping Nginx
* Stopping nginx nginx
   ...done.
Generating/Renewing certificate

[...]

letsencrypt: error: argument -m/--email: expected one argument
Restarting web server
* Starting nginx nginx
   ...done.

 

Restarting the container did the trick, but thats not how its upposed to work :)

 

*** Running /etc/my_init.d/00_regen_ssh_host_keys.sh...
*** Running /etc/my_init.d/firstrun.sh...
Using existing nginx.conf
Using existing nginx-fpm.conf
Using existing site config
Using existing landing page
Using existing jail.local
Using existing fail2ban filters
SUBDOMAINS entered, processing
Sub-domains processed are: -d XXX.XXXX.XX -d XXX.XXXX.XX -d XXX.XXXX.XX -d XXX.XXXX.XX -d XXX.XXXX.XX -d XXX.XXXX.XX
Using existing DH parameters
<------------------------------------------------->

<------------------------------------------------->
cronjob running at Sat Jun 18 12:13:19 CEST 2016
Updating certbot script. It will display help info, which you can ignore

[...]

URL is stweb.pw
Subdomains are extern,unraid,owncloud,prtg,vpn,3cx
deciding whether to renew the cert(s)
Preparing to renew certificate that is older than 60 days
Temporarily stopping Nginx
* Stopping nginx nginx
...done.
Generating/Renewing certificate
...done.
Generating/Renewing certificate
2016-06-18 12:13:32,741:WARNING:certbot.main:Renewal conf file /etc/letsencrypt/renewal/XXXX.XX.conf is broken. Skipping.

IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/XXXX.XX-0001/fullchain.pem. Your cert will
expire on 2016-09-16. To obtain a new or tweaked version of this

certificate in the future, simply run certbot-auto again. To
non-interactively renew *all* of your certificates, run
"certbot-auto renew"
- If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

Restarting web server
* Starting nginx nginx
...done.
* Starting nginx nginx
...done.
fail2ban.sock found, deleting
* Starting authentication failure monitor fail2ban
...done.
*** Running /etc/rc.local...
*** Booting runit daemon...
*** Runit started as PID 207
Jun 18 12:13:43 db60a164cff2 syslog-ng[215]: syslog-ng starting up; version='3.5.3'

Jun 18 12:17:01 db60a164cff2 /USR/SBIN/CRON[231]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)

 

Maybe the Warning about the "broken" renewal conf had something to do with it?

Or some typo in your renewal cron that misses the mail parameter?

Or is it something on my end?

 

EDIT: Spoke to soon. Renewal worked, but its still using the old certs and is therefore renewing on every restart and maybe every cronjob...

 

Probably a broken !keys link? I think its supposed to point to ... /etc/letsencrypt/live/<domain> which it probably does, but the new certs are now in <domain>-0001. Not sure which one is wrong, folder or symlink.

 

EDIT2: I think I found the reason, you added some mechanism to identify changed domains... probably because you ran into the same issue?

2016-06-03 - Added ability to change url and subdomains (container will automatically recognize changes to the variables upon start, and will update the cert accordingly)

I asumed is would recognize past changes and did not double check your tracking file.

 

I changed the domain (added a subdomain) before you patched it, so it couldn't just renew everthing but had to create a new folder... maybe also the reason for the "boken" renewal conf and maybe even the missing mail parameter?

 

Maybe you should not have tracked the docker parameter in your file, but the domains that are currently in the cert and compare them on start with the parameter? You would have been able to recognize past changes.

Now it should be fine, but if someone changed their domain before you added this feature, they may run into the same issue.

Maybe adding a reason for a change to your release notes or in this case mention that it would ONLY recognize future changes not past ones?

I would have been warned that way :)

 

I am not complaining, just some suggestions if you are interested :) I usualy read patchnotes and enjoy detailed ones, with explanations. Obvoisly timeconsuming, so I understand If you dont explain everything ;)

 

I guess I will clean up the cert folder and start clean.

 

EDIT3: Oh and one last thing. My access.log is already 14MB+ and its not even a heavily used proxy. Do you have any kind of log-rotation in place? if not maybe add some and compress old logs? Maybe size depended or every 90 days or on every renewal? Just some suggetions :)

live-folder.PNG.d3f46b0ad05dfdb5e6650f5a20ed3d91.PNG

Share this post


Link to post

Renewal was up, but failed:

cronjob running at Sat Jun 18 02:00:01 CEST 2016
Updating certbot script. It will display help info, which you can ignore

[...]

URL is XXXX.XX
Subdomains are
deciding whether to renew the cert(s)
Preparing to renew certificate that is older than 60 days
Temporarily stopping Nginx
* Stopping nginx nginx
   ...done.
Generating/Renewing certificate

[...]

letsencrypt: error: argument -m/--email: expected one argument
Restarting web server
* Starting nginx nginx
   ...done.

 

Restarting the container did the trick, but thats not how its upposed to work :)

 

*** Running /etc/my_init.d/00_regen_ssh_host_keys.sh...
*** Running /etc/my_init.d/firstrun.sh...
Using existing nginx.conf
Using existing nginx-fpm.conf
Using existing site config
Using existing landing page
Using existing jail.local
Using existing fail2ban filters
SUBDOMAINS entered, processing
Sub-domains processed are: -d XXX.XXXX.XX -d XXX.XXXX.XX -d XXX.XXXX.XX -d XXX.XXXX.XX -d XXX.XXXX.XX -d XXX.XXXX.XX
Using existing DH parameters
<------------------------------------------------->

<------------------------------------------------->
cronjob running at Sat Jun 18 12:13:19 CEST 2016
Updating certbot script. It will display help info, which you can ignore

[...]

URL is stweb.pw
Subdomains are extern,unraid,owncloud,prtg,vpn,3cx
deciding whether to renew the cert(s)
Preparing to renew certificate that is older than 60 days
Temporarily stopping Nginx
* Stopping nginx nginx
...done.
Generating/Renewing certificate
...done.
Generating/Renewing certificate
2016-06-18 12:13:32,741:WARNING:certbot.main:Renewal conf file /etc/letsencrypt/renewal/XXXX.XX.conf is broken. Skipping.

IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/XXXX.XX-0001/fullchain.pem. Your cert will
expire on 2016-09-16. To obtain a new or tweaked version of this

certificate in the future, simply run certbot-auto again. To
non-interactively renew *all* of your certificates, run
"certbot-auto renew"
- If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

Restarting web server
* Starting nginx nginx
...done.
* Starting nginx nginx
...done.
fail2ban.sock found, deleting
* Starting authentication failure monitor fail2ban
...done.
*** Running /etc/rc.local...
*** Booting runit daemon...
*** Runit started as PID 207
Jun 18 12:13:43 db60a164cff2 syslog-ng[215]: syslog-ng starting up; version='3.5.3'

Jun 18 12:17:01 db60a164cff2 /USR/SBIN/CRON[231]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)

 

Maybe the Warning about the "broken" renewal conf had something to do with it?

Or some typo in your renewal cron that misses the mail parameter?

Or is it something on my end?

 

EDIT: Spoke to soon. Renewal worked, but its still using the old certs and is therefore renewing on every restart and maybe every cronjob...

 

Probably a broken !keys link? I think its supposed to point to ... /etc/letsencrypt/live/<domain> which it probably does, but the new certs are now in <domain>-0001. Not sure which one is wrong, folder or symlink.

 

EDIT2: I think I found the reason, you added some mechanism to identify changed domains... probably because you ran into the same issue?

2016-06-03 - Added ability to change url and subdomains (container will automatically recognize changes to the variables upon start, and will update the cert accordingly)

I asumed is would recognize past changes and did not double check your tracking file.

 

I changed the domain (added a subdomain) before you patched it, so it couldn't just renew everthing but had to create a new folder... maybe also the reason for the "boken" renewal conf and maybe even the missing mail parameter?

 

Maybe you should not have tracked the docker parameter in your file, but the domains that are currently in the cert and compare them on start with the parameter? You would have been able to recognize past changes.

Now it should be fine, but if someone changed their domain before you added this feature, they may run into the same issue.

Maybe adding a reason for a change to your release notes or in this case mention that it would ONLY recognize future changes not past ones?

I would have been warned that way :)

 

I am not complaining, just some suggestions if you are interested :) I usualy read patchnotes and enjoy detailed ones, with explanations. Obvoisly timeconsuming, so I understand If you dont explain everything ;)

 

I guess I will clean up the cert folder and start clean.

 

EDIT3: Oh and one last thing. My access.log is already 14MB+ and its not even a heavily used proxy. Do you have any kind of log-rotation in place? if not maybe add some and compress old logs? Maybe size depended or every 90 days or on every renewal? Just some suggetions :)

 

The problem was exactly that. You changed the parameters after install and did not delete the /config/etc/letsencrypt folder. Previously, you had to delete that folder and there was a disclaimer in the description of the container.

 

I have since added the mechanism to track changes to the parameters, but your container was already broken before that. It was waiting for the renewal to stop working and it did.

 

There is log rotation built in to nginx. I'll check to see if it's not working properly.

 

The email related error could be a temporary glitch likely on the server side because this container uses the same script for cron renewals and during startup. If you just let it run, it would have attempted again the next night and likely would have gone through

 

Share this post


Link to post

there was a disclaimer in the description of the container.

I probably read it and forgot about it when I added the subdomain :)

 

There is log rotation built in to nginx. I'll check to see if it's not working properly.

Hm, thats not what I can read here, but maybe thats an older version.

 

The email related error could be a temporary glitch likely on the server side because this container uses the same script for cron renewals and during startup. If you just let it run, it would have attempted again the next night and likely would have gone through

To be precise, renewal was up yesterday, so it failed twice, 17th and 18th with the same error.

 

cronjob running at Thu Jun 16 02:00:01 CEST 2016
Updating certbot script. It will display help info, which you can ignore

deciding whether to renew the cert(s)
Existing certificate is still valid for another 31 day(s); skipping renewal.
<------------------------------------------------->

<------------------------------------------------->
cronjob running at Fri Jun 17 02:00:01 CEST 2016
Updating certbot script. It will display help info, which you can ignore

deciding whether to renew the cert(s)
Preparing to renew certificate that is older than 60 days

Temporarily stopping Nginx
* Stopping nginx nginx
   ...done.
   
letsencrypt: error: argument -m/--email: expected one argument

Restarting web server
* Starting nginx nginx
   ...done.
<------------------------------------------------->

<------------------------------------------------->
cronjob running at Sat Jun 18 02:00:01 CEST 2016
Updating certbot script. It will display help info, which you can ignore

deciding whether to renew the cert(s)
Preparing to renew certificate that is older than 60 days

Temporarily stopping Nginx
* Stopping nginx nginx
   ...done.

letsencrypt: error: argument -m/--email: expected one argument

Restarting web server
* Starting nginx nginx
   ...done.

 

But if the whole process was "broken", because I added the subdomain and did not proberly remove any folders, who knows what other glitches could be a result of that.

I have your container running on two other servers, I'll see how it goes there :)

 

Thanks for the quick reply and have a nice weekend :)

Share this post


Link to post

there was a disclaimer in the description of the container.

I probably read it and forgot about it when I added the subdomain :)

 

There is log rotation built in to nginx. I'll check to see if it's not working properly.

Hm, thats not what I can read here, but maybe thats an older version.

 

The email related error could be a temporary glitch likely on the server side because this container uses the same script for cron renewals and during startup. If you just let it run, it would have attempted again the next night and likely would have gone through

To be precise, renewal was up yesterday, so it failed twice, 17th and 18th with the same error.

 

cronjob running at Thu Jun 16 02:00:01 CEST 2016
Updating certbot script. It will display help info, which you can ignore

deciding whether to renew the cert(s)
Existing certificate is still valid for another 31 day(s); skipping renewal.
<------------------------------------------------->

<------------------------------------------------->
cronjob running at Fri Jun 17 02:00:01 CEST 2016
Updating certbot script. It will display help info, which you can ignore

deciding whether to renew the cert(s)
Preparing to renew certificate that is older than 60 days

Temporarily stopping Nginx
* Stopping nginx nginx
   ...done.
   
letsencrypt: error: argument -m/--email: expected one argument

Restarting web server
* Starting nginx nginx
   ...done.
<------------------------------------------------->

<------------------------------------------------->
cronjob running at Sat Jun 18 02:00:01 CEST 2016
Updating certbot script. It will display help info, which you can ignore

deciding whether to renew the cert(s)
Preparing to renew certificate that is older than 60 days

Temporarily stopping Nginx
* Stopping nginx nginx
   ...done.

letsencrypt: error: argument -m/--email: expected one argument

Restarting web server
* Starting nginx nginx
   ...done.

 

But if the whole process was "broken", because I added the subdomain and did not proberly remove any folders, who knows what other glitches could be a result of that.

I have your container running on two other servers, I'll see how it goes there :)

 

Thanks for the quick reply and have a nice weekend :)

 

I looked into the missing email parameter and that was my bad. When it is run from cron, the cron environment did not have access to the email parameter set. Older versions of the renewal script didn't complain about that so I never realized. It will be fixed in the next update.

 

Log rotation was on, but the default setting was incorrect (looking for the log files under /var/log/nginx). Fixed in the next update.

 

Once you delete the /config/etc/letsencrypt folder, you are pretty much starting over with fresh certificates. You shouldn't have any issues going forward (It's ok to delete that folder every once in a while, but if you do it too much, letsencrypt servers will block renewals or new cert generation for a while to prevent abuse).

Share this post


Link to post

Well, that was fast! Thanks again.

 

I added a new subdomain (owncloud -> nextcloud  ::)), and everything went its way.

Folder got deleted and everything seems fine for now.

Share this post


Link to post

I've installed this docker and the log shows that the certificates were created. When I go to the letsencrypt docker webui, I see the default landing page that says the webserver is working properly.  However, chrome still displays the lock with the red "X" indicating that the page is insecure. Is there something else that I need to do to get the green lock?

Share this post


Link to post

I've installed this docker and the log shows that the certificates were created. When I go to the letsencrypt docker webui, I see the default landing page that says the webserver is working properly.  However, chrome still displays the lock with the red "X" indicating that the page is insecure. Is there something else that I need to do to get the green lock?

Did you click on the webui link to open the page? You're supposed to go to the domain you got the certificate for. Otherwise the url doesn't match the certificate address and Google throws an error

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now