Originally created by @thejustsoul on GitHub (Dec 6, 2015).
Hello. Your script very nice and simple!
Have questions:
how to revoke cert? For one domain\sub-domain. For all domain.
how to renew cert? For one domain\sub-domain. For all domain.
how to use email (to notify about the expiry dates) if already use in official client..
need or no need (and how) import account data from official client if before already generate for domain certs?
crontab - simple add letsencrypt.sh to cron, no need params for script?
your client are stable and production ready?
It would be nice if you added a FAQ for newbies (and not only).
While that is all the questions)
Originally created by @thejustsoul on GitHub (Dec 6, 2015).
Hello. Your script very nice and simple!
Have questions:
1. how to `revoke` cert? For one domain\sub-domain. For all domain.
2. how to `renew` cert? For one domain\sub-domain. For all domain.
3. how to use email (to notify about the expiry dates) if already use in official client..
4. need or no need (and how) import account data from official client if before already generate for domain certs?
5. crontab - simple add `letsencrypt.sh` to cron, no need params for script?
6. your client are stable and production ready?
It would be nice if you added a FAQ for newbies (and not only).
While that is all the questions)
just run the script, it renews all available domains (which have a directory)
not implemented yet
you need to "import" the list of domains and put them into "domains.txt", if you want to reuse the old private keys, see 2)
yes, but cd to the right directory first. Also run it only every 30 days or so as it will resign all domains on each run (if you do that daily you'll run into rate limiting)
it's 1 day old, so not stable ;-) - production ready depends on your definition I guess, works fine for me so far
@rudis commented on GitHub (Dec 6, 2015):
1. not implemented yet
2. just run the script, it renews all available domains (which have a directory)
3. not implemented yet
4. you need to "import" the list of domains and put them into "domains.txt", if you want to reuse the old private keys, see 2)
5. yes, but cd to the right directory first. Also run it only every 30 days or so as it will resign all domains on each run (if you do that daily you'll run into rate limiting)
6. it's 1 day old, so not stable ;-) - production ready depends on your definition I guess, works fine for me so far
Thanks for reply.
If not difficult, do as in the original client - privkey.pem, cert.pem, chain.pem, fullchain.pem.
I will watch for updates. Loved the script in terms of what is conventionally only 1 file (exclude perl script and configs), not a bunch of incomprehensible Python as some.. (sorry for my bad english)
Offtop: Don't know for what the original client need e-mail? Only for notifications about the expiry dates?
@thejustsoul commented on GitHub (Dec 6, 2015):
Thanks for reply.
If not difficult, do as in the original client - privkey.pem, cert.pem, chain.pem, fullchain.pem.
I will watch for updates. Loved the script in terms of what is conventionally only 1 file (exclude perl script and configs), not a bunch of incomprehensible Python as some.. (sorry for my bad english)
Offtop: Don't know for what the original client need e-mail? Only for notifications about the expiry dates?
@einervonvielen commented on GitHub (Dec 7, 2015):
I would like to use your client for Apache under Debian.
What do I have to do step-by-step (or at least a little bit more explained than in the readme)?
Do I need a running webserver (Apache)?
Do I need to edit the apache config files?
In what directory do I have to run the script?
@einervonvielen commented on GitHub (Dec 7, 2015):
I would like to use your client for Apache under Debian.
What do I have to do step-by-step (or at least a little bit more explained than in the readme)?
Do I need a running webserver (Apache)?
Do I need to edit the apache config files?
In what directory do I have to run the script?
@einervonvielen please keep in mind that this is not designed to be an easy all-in-one installer and authenticator tool like the original client is. This script is just doing the bare minimum. To get started you'll have to configure your webserver to serve the challenge-response ($WELLKNOWN) directory and fill in domains.txt with your domains.
@lukas2511 commented on GitHub (Dec 7, 2015):
@einervonvielen please keep in mind that this is not designed to be an easy all-in-one installer and authenticator tool like the original client is. This script is just doing the bare minimum. To get started you'll have to configure your webserver to serve the challenge-response (`$WELLKNOWN`) directory and fill in domains.txt with your domains.
@thejustsoul i think the email address is designed to be a last way of authentication for recovery, probably if you loose your certificates (including private account key) and want to revoke everything, but i'm not sure. read the spec, it's probably somewhere in there :D
@lukas2511 commented on GitHub (Dec 7, 2015):
@thejustsoul i think the email address is designed to be a last way of authentication for recovery, probably if you loose your certificates (including private account key) and want to revoke everything, but i'm not sure. read the spec, it's probably somewhere in there :D
letsencrypt.sh must be run from /var/www/letsencrypt
Right?
@einervonvielen commented on GitHub (Dec 7, 2015):
@lukas2511 thanks. Just to make it a bit easier for everyone and for me...
1) the letsencrypt server will call back http:/mycooldomain/.well-known/acme-challenge
Right?
2) So if for nginx
```
location /.well-known/acme-challenge {
root /var/www/letsencrypt;
}
```
letsencrypt.sh must be run from /var/www/letsencrypt
Right?
no, you don't have to move it there, you can configure the output directory for challenge-response files in config.sh (e.g. WELLKNOWN=/var/www/letsencrypt/.well-known/acme-challenge)
Since this script is intended for the more experienced users I don't have any priority of making it easier to use, even though it's actually super easy to use once you get it running.
I'll lock the conversation in this ticket until there is progress to the original questions and issues this ticket was intended for.
@lukas2511 commented on GitHub (Dec 7, 2015):
@einervonvielen
1) yes
2) no, you don't have to move it there, you can configure the output directory for challenge-response files in config.sh (e.g. WELLKNOWN=/var/www/letsencrypt/.well-known/acme-challenge)
Since this script is intended for the more experienced users I don't have any priority of making it easier to use, even though it's actually super easy to use once you get it running.
I'll lock the conversation in this ticket until there is progress to the original questions and issues this ticket was intended for.
1. how to revoke cert? For one domain\sub-domain. For all domain.
For now (syntax may change): ./letsencrypt.sh revoke path/to/cert.pem
Won't implement a command to revoke all certificates at once, this seems more dangerous than practical, especially with current api-limits on letsencrypt.
2. how to renew cert? For one domain\sub-domain. For all domain.
For now: ./letsencrypt.sh will sign all new and near expired cerificates.
I will probably implement a feature to force resigning of a specific certificate.
3. how to use email (to notify about the expiry dates) if already use in official client..
Not sure how that works, if letsencrypt sends the mails you can probably just import your existing key with registered mail and it will continue working
4. need or no need (and how) import account data from official client if before already generate for domain certs?
There are now two scripts for importing data that are described in the README file
5. crontab - simple add letsencrypt.sh to cron, no need params for script?
See 2.
6. your client are stable and production ready?
No.
This script is hacked together in multiple places, parsing and generating JSON in bash is pretty much impossible, there are several workarounds around how things work, and it will probably never reach the stability of the official letsencrypt client.
I wouldn't recommend relying on this to work, but if you are handling it manually and roll out certificates after additional verification it's more than good enough.
@lukas2511 commented on GitHub (Dec 7, 2015):
@thejustsoul
##### 1. how to revoke cert? For one domain\sub-domain. For all domain.
For now (syntax may change): `./letsencrypt.sh revoke path/to/cert.pem`
Won't implement a command to revoke all certificates at once, this seems more dangerous than practical, especially with current api-limits on letsencrypt.
##### 2. how to renew cert? For one domain\sub-domain. For all domain.
For now: `./letsencrypt.sh` will sign all new and near expired cerificates.
I will probably implement a feature to force resigning of a specific certificate.
##### 3. how to use email (to notify about the expiry dates) if already use in official client..
Not sure how that works, if letsencrypt sends the mails you can probably just import your existing key with registered mail and it will continue working
##### 4. need or no need (and how) import account data from official client if before already generate for domain certs?
There are now two scripts for importing data that are described in the README file
##### 5. crontab - simple add letsencrypt.sh to cron, no need params for script?
See 2.
##### 6. your client are stable and production ready?
No.
This script is hacked together in multiple places, parsing and generating JSON in bash is pretty much impossible, there are several workarounds around how things work, and it will probably never reach the stability of the official letsencrypt client.
I wouldn't recommend relying on this to work, but if you are handling it manually and roll out certificates after additional verification it's more than good enough.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @thejustsoul on GitHub (Dec 6, 2015).
Hello. Your script very nice and simple!
Have questions:
revokecert? For one domain\sub-domain. For all domain.renewcert? For one domain\sub-domain. For all domain.letsencrypt.shto cron, no need params for script?It would be nice if you added a FAQ for newbies (and not only).
While that is all the questions)
@rudis commented on GitHub (Dec 6, 2015):
@thejustsoul commented on GitHub (Dec 6, 2015):
Thanks for reply.
If not difficult, do as in the original client - privkey.pem, cert.pem, chain.pem, fullchain.pem.
I will watch for updates. Loved the script in terms of what is conventionally only 1 file (exclude perl script and configs), not a bunch of incomprehensible Python as some.. (sorry for my bad english)
Offtop: Don't know for what the original client need e-mail? Only for notifications about the expiry dates?
@einervonvielen commented on GitHub (Dec 7, 2015):
I would like to use your client for Apache under Debian.
What do I have to do step-by-step (or at least a little bit more explained than in the readme)?
Do I need a running webserver (Apache)?
Do I need to edit the apache config files?
In what directory do I have to run the script?
@lukas2511 commented on GitHub (Dec 7, 2015):
@einervonvielen please keep in mind that this is not designed to be an easy all-in-one installer and authenticator tool like the original client is. This script is just doing the bare minimum. To get started you'll have to configure your webserver to serve the challenge-response (
$WELLKNOWN) directory and fill in domains.txt with your domains.@lukas2511 commented on GitHub (Dec 7, 2015):
@thejustsoul i think the email address is designed to be a last way of authentication for recovery, probably if you loose your certificates (including private account key) and want to revoke everything, but i'm not sure. read the spec, it's probably somewhere in there :D
@einervonvielen commented on GitHub (Dec 7, 2015):
@lukas2511 thanks. Just to make it a bit easier for everyone and for me...
Right?
letsencrypt.sh must be run from /var/www/letsencrypt
Right?
@lukas2511 commented on GitHub (Dec 7, 2015):
@einervonvielen
yes
no, you don't have to move it there, you can configure the output directory for challenge-response files in config.sh (e.g. WELLKNOWN=/var/www/letsencrypt/.well-known/acme-challenge)
Since this script is intended for the more experienced users I don't have any priority of making it easier to use, even though it's actually super easy to use once you get it running.
I'll lock the conversation in this ticket until there is progress to the original questions and issues this ticket was intended for.
@lukas2511 commented on GitHub (Dec 7, 2015):
@thejustsoul
1. how to revoke cert? For one domain\sub-domain. For all domain.
For now (syntax may change):
./letsencrypt.sh revoke path/to/cert.pemWon't implement a command to revoke all certificates at once, this seems more dangerous than practical, especially with current api-limits on letsencrypt.
2. how to renew cert? For one domain\sub-domain. For all domain.
For now:
./letsencrypt.shwill sign all new and near expired cerificates.I will probably implement a feature to force resigning of a specific certificate.
3. how to use email (to notify about the expiry dates) if already use in official client..
Not sure how that works, if letsencrypt sends the mails you can probably just import your existing key with registered mail and it will continue working
4. need or no need (and how) import account data from official client if before already generate for domain certs?
There are now two scripts for importing data that are described in the README file
5. crontab - simple add letsencrypt.sh to cron, no need params for script?
See 2.
6. your client are stable and production ready?
No.
This script is hacked together in multiple places, parsing and generating JSON in bash is pretty much impossible, there are several workarounds around how things work, and it will probably never reach the stability of the official letsencrypt client.
I wouldn't recommend relying on this to work, but if you are handling it manually and roll out certificates after additional verification it's more than good enough.