astlinux-devel Mailing List for AstLinux

Announcing Pre-Release Version: astlinux-1.0-8118

Release Candidate for AstLinux 1.2.9

The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own.

-- IPsec VPN (strongSwan) Configuration
http://doc.astlinux-project.org/userdoc:tt_ipsec_vpn_strongswan

-- NTP Client/Server (chrony) Configuration
http://doc.astlinux-project.org/userdoc:tt_ntp_client_server

-- OpenVPN, major version bump to 2.4.0, new features include AEAD (GCM) cipher and Elliptic Curve DH key exchange support.

These pre-release images are for those who would like to take advantage of the AstLinux development before the next official release, as well as providing testing for the project.

The "AstLinux Pre-Release ChangeLog" and "Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...

AstLinux Project -> Development
http://www.astlinux-project.org/dev.html

If you should come across an issue, please report back here ASAP.

AstLinux Team

Announcing Pre-Release Version: astlinux-1.0-8091

The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own.

-- IPsec VPN (strongSwan) Configuration
http://doc.astlinux-project.org/userdoc:tt_ipsec_vpn_strongswan

-- NTP Client/Server (chrony) Configuration
http://doc.astlinux-project.org/userdoc:tt_ntp_client_server

-- OpenVPN, major version bump to 2.4.0, new features include AEAD (GCM) cipher and Elliptic Curve DH key exchange support.

These pre-release images are for those who would like to take advantage of the AstLinux development before the next official release, as well as providing testing for the project.

The "AstLinux Pre-Release ChangeLog" and "Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...

AstLinux Project -> Development
http://www.astlinux-project.org/dev.html

If you should come across an issue, please report back here ASAP before the official AstLinux 1.2.9 release.

AstLinux Team

David, all good points.

I'd rather use ACME (Automatic Certificate Management Environment) instead of LETSENCRYPT for naming things, as the protocol is ACME and down the road other ACME providers may exist.

Lonnie



On Jan 12, 2017, at 2:19 PM, David Kerr <Da...@Ke...> wrote:

> Thanks Lonnie,
>   I was thinking of a couple of other changes to the script as well...
> 
> 1) Wrap the whole thing with something like if HTTPS_LETSENCRYPT = yes so there is an easy way to turn on/off
> 2) Add a test to check that $_cfullchain file exists.  If it does not then $HTTPSCHAIN should be deleted.  Right now we assume that LetsEncrypt passes us intermediate certificates, but I don't know if that is a future-proof assumption.
> 
> I don't like that acme.sh both executes and saves data in the same directory... I was always taught to separate executable code from the data store.  How we install and run does need a bit of thinking.
> 
> For now LetsEncrypt is definitely in the realm of expert only with a lot more thinking/work before including in a default AstLinux build.  Questions like whether to use it for OpenVPN (OVPN_LETSENCRYPT = yes) and SIP/TLS and IPSEC, etc.
> 
> David
> 
> 
> 
> On Thu, Jan 12, 2017 at 12:58 PM, Lonnie Abelbeck <li...@lo...> wrote:
> Great work David.
> 
> I'd suggest adding two lines, since HTTPSCERT includes a private key set mode 600, and add a sleep 1 to allow the stopping of lighttpd to settle down.
> --
>   if [ -n "$HTTPSCERT" ]; then
>     service lighttpd stop
>     cat "$_ckey" "$_ccert" > "$HTTPSCERT"
> +  chmod 600 "$HTTPSCERT"
>     if [ -n "$HTTPSCHAIN" ]; then
>       cat "$_cfullchain" > "$HTTPSCHAIN"
>     fi
> +  sleep 1
>     service lighttpd init
>   fi
> --
> 
> BTW, I independently spent a couple hours researching ACME clients and came to the same conclusion as you acme.sh  https://github.com/Neilpang/acme.sh is the best for AstLinux, and seems to be one of the only clients that supports DNS TXT validation.  Also pfSense has recently decided to use acme.sh as well.
> 
> acme.sh uses vanilla shell, curl and openssl as dependencies, perfect for us.
> 
> As you suggested David, we probably should add this to the build system ... a work in progress and disabled by default.
> 
> My thoughts on naming ...
> 
> package "acme"
> 
> /etc/acme -> /mnt/kd/acme/
> 
> /etc/ssl/acme -> /mnt/kd/ssl/acme/
> 
> Possibly Install into /stat/etc/acme/ and run under /mnt/kd/acme/ but this is looking tricky to do at build time as acme.sh --install tries to be "smart" and is more of a target method.
> 
> Hmmm, more thinking required ...  possibly we can set USER_PATH="/mnt/kd/acme" and act like IN_CRON=1 .
> 
> Lonnie
> 
> 
> On Jan 11, 2017, at 9:10 PM, David Kerr <Da...@Ke...> wrote:
> 
> > Thanks Lonnie.  I now have a trusted certificate working for lighttpd HTTPS on AstLinux.  Here is what I did...
> >
> > Add HTTPSCHAIN=/mnt/kd/ssl/https_ca_chain.pem to user.conf
> >
> > Install acme.sh (see https://github.com/Neilpang/acme.sh) on my astlinux.  From ~ (root home)...
> >
> > curl https://codeload.github.com/Neilpang/acme.sh/tar.gz/master > acme.sh-master.tar.gz
> > tar xzf acme.sh-master.tar.gz
> > cd acme.sh-master
> > ./acme.sh --install --home /etc/acme.sh --accountemail "your@email.here" --useragent "AstLinux"
> >
> > The process of installing should ideally be done as part of AstLinux build... we could add a package "letsencrypt" which gets acme.sh and places it into the right directory (I chose /etc/acme.sh).  Though the last part which sets account email would have to be done later.  Note that the install process adds a crontab as well which is needed for auto renew.
> >
> > Add a script file...  /etc/acme.sh/deploy/astlinux.sh which contains the following (modeled on their template)...
> >
> > #!/usr/bin/env bash
> >
> > #Here is a sample custom api script.
> > #This file name is "myapi.sh"
> > #So, here must be a method   myapi_deploy()
> > #Which will be called by acme.sh to deploy the cert
> > #returns 0 means success, otherwise error.
> >
> > . /etc/rc.conf
> >
> > ########  Public functions #####################
> >
> > #domain keyfile certfile cafile fullchain
> > astlinux_deploy() {
> >   _cdomain="$1"
> >   _ckey="$2"
> >   _ccert="$3"
> >   _cca="$4"
> >   _cfullchain="$5"
> >
> >   _debug _cdomain "$_cdomain"
> >   _debug _ckey "$_ckey"
> >   _debug _ccert "$_ccert"
> >   _debug _cca "$_cca"
> >   _debug _cfullchain "$_cfullchain"
> >
> >   if [ -n "$HTTPSCERT" ]; then
> >     service lighttpd stop
> >     cat "$_ckey" "$_ccert" > "$HTTPSCERT"
> >     if [ -n "$HTTPSCHAIN" ]; then
> >       cat "$_cfullchain" > "$HTTPSCHAIN"
> >     fi
> >     service lighttpd init
> >   fi
> >   return 0
> > }
> >
> > This takes care of lighttpd... but the deploy script could be expanded to handle SIP-TLS or other places that you want to use the same certificate.
> >
> > Now request a certificate...
> >
> > /etc/acme.sh/acme.sh --home /etc/acme.sh --issue -d yourdomain.tld -w /home/ftp/www -d pbx.youdomain.tld -d sip.yourdomain.tld
> >
> > You can add multiple domains with -d flag (all must be valid public URLs that can be validated as owned by you).
> > This assumes that HTTPDIR is /home/ftp/www (ideally we should wrap this in a script that gets it from $HTTPDIR)  and that port 80 is open... validating domains by DNS is for another day... this method gets me started.
> >
> > Now deploy the certificate...
> >
> > /etc/acme.sh/acme.sh --home /etc/acme.sh --deploy -d yourdomain.tld --deploy-hook astlinux
> >
> > Which runs the above astlinux.sh file we placed in /etc/acme.sh/deploy directory.  Note that the script does a stop / init on lighttpd because a restart would not be good enough (because the ca chain file might not exist when init is first run)
> >
> > Now whenever the certificate is renewed, the certificates are updated and the deploy script is run automatically.  This would be triggered by the cron job.
> >
> > If you start to play with this, be sure to add --test to all acme.sh commands during your testing.... to point it at a test server.  LetsEncrypt limits the number of times you can request/renew a certificate each week which you could easily hit during testing.  When ready to use a real certificate, --revoke the test ones and then --issue from non-test server.
> >
> > David
> >
> > On Wed, Jan 11, 2017 at 1:19 PM, Lonnie Abelbeck <li...@lo...> wrote:
> > Hi David,
> >
> > #2 solved, a good feature to have for completeness.  Specify in user.conf.
> >
> > https://sourceforge.net/p/astlinux/code/8089
> >
> > Lonnie
> >
> >
> > On Jan 10, 2017, at 10:40 PM, David Kerr <Da...@Ke...> wrote:
> >
> > > Tonights discoveries on this topic...
> > >
> > >       • Lighttpd loads certificates at startup only, so service will need to be stopped and started again each time the certificates are renewed (60 days).
> > >       • LetsEncrypt is issuing chained certificates, the intermediate certificates may not be included in browsers.  You therefore have to add the chain to the web server.  So lighttpd.conf needs a ssl.ca-file set in addition to ssl.pemfile.
> > >       • LetsEncrypt issues the cert and key as two separate files.  The pem file that lighttpd needs has to be created each time the certs renew.
> > >       • the DNS registrar that I use (freeDNS) does not have an API to update TXT records.  Admin there suggests using POST to the subdomain web site... in other words need to create my own API !
> > > Nothing is ever easy, Huh?
> > >
> > > For #1 and #3... I will need to create a script to create the pem file and restart lighttpd. Should be easy enough.
> > > For #2... to maintain autogenerated lighttpd.conf file, need support for chain CA files added to the web interface (or recognize a variable we can set in user.conf, e.g. HTTPSCHAIN=/mnt/kd/ssl/mydomain.tld/fullchain.cer) and update /etc/init.d/lighttpd init() function to recognize it.
> > > For #4... more thinking to be done.
> > >
> > > David
> 
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi_______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Thanks Lonnie,
  I was thinking of a couple of other changes to the script as well...

1) Wrap the whole thing with something like if HTTPS_LETSENCRYPT = yes so
there is an easy way to turn on/off
2) Add a test to check that $_cfullchain file exists.  If it does not then
$HTTPSCHAIN should be deleted.  Right now we assume that LetsEncrypt passes
us intermediate certificates, but I don't know if that is a future-proof
assumption.

I don't like that acme.sh both executes and saves data in the same
directory... I was always taught to separate executable code from the data
store.  How we install and run does need a bit of thinking.

For now LetsEncrypt is definitely in the realm of expert only with a lot
more thinking/work before including in a default AstLinux build.  Questions
like whether to use it for OpenVPN (OVPN_LETSENCRYPT = yes) and SIP/TLS and
IPSEC, etc.

David



On Thu, Jan 12, 2017 at 12:58 PM, Lonnie Abelbeck <li...@lo...
> wrote:

> Great work David.
>
> I'd suggest adding two lines, since HTTPSCERT includes a private key set
> mode 600, and add a sleep 1 to allow the stopping of lighttpd to settle
> down.
> --
>   if [ -n "$HTTPSCERT" ]; then
>     service lighttpd stop
>     cat "$_ckey" "$_ccert" > "$HTTPSCERT"
> +  chmod 600 "$HTTPSCERT"
>     if [ -n "$HTTPSCHAIN" ]; then
>       cat "$_cfullchain" > "$HTTPSCHAIN"
>     fi
> +  sleep 1
>     service lighttpd init
>   fi
> --
>
> BTW, I independently spent a couple hours researching ACME clients and
> came to the same conclusion as you acme.sh  https://github.com/Neilpang/
> acme.sh is the best for AstLinux, and seems to be one of the only clients
> that supports DNS TXT validation.  Also pfSense has recently decided to use
> acme.sh as well.
>
> acme.sh uses vanilla shell, curl and openssl as dependencies, perfect for
> us.
>
> As you suggested David, we probably should add this to the build system
> ... a work in progress and disabled by default.
>
> My thoughts on naming ...
>
> package "acme"
>
> /etc/acme -> /mnt/kd/acme/
>
> /etc/ssl/acme -> /mnt/kd/ssl/acme/
>
> Possibly Install into /stat/etc/acme/ and run under /mnt/kd/acme/ but this
> is looking tricky to do at build time as acme.sh --install tries to be
> "smart" and is more of a target method.
>
> Hmmm, more thinking required ...  possibly we can set
> USER_PATH="/mnt/kd/acme" and act like IN_CRON=1 .
>
> Lonnie
>
>
> On Jan 11, 2017, at 9:10 PM, David Kerr <Da...@Ke...> wrote:
>
> > Thanks Lonnie.  I now have a trusted certificate working for lighttpd
> HTTPS on AstLinux.  Here is what I did...
> >
> > Add HTTPSCHAIN=/mnt/kd/ssl/https_ca_chain.pem to user.conf
> >
> > Install acme.sh (see https://github.com/Neilpang/acme.sh) on my
> astlinux.  From ~ (root home)...
> >
> > curl https://codeload.github.com/Neilpang/acme.sh/tar.gz/master >
> acme.sh-master.tar.gz
> > tar xzf acme.sh-master.tar.gz
> > cd acme.sh-master
> > ./acme.sh --install --home /etc/acme.sh --accountemail "your@email.here"
> --useragent "AstLinux"
> >
> > The process of installing should ideally be done as part of AstLinux
> build... we could add a package "letsencrypt" which gets acme.sh and places
> it into the right directory (I chose /etc/acme.sh).  Though the last part
> which sets account email would have to be done later.  Note that the
> install process adds a crontab as well which is needed for auto renew.
> >
> > Add a script file...  /etc/acme.sh/deploy/astlinux.sh which contains
> the following (modeled on their template)...
> >
> > #!/usr/bin/env bash
> >
> > #Here is a sample custom api script.
> > #This file name is "myapi.sh"
> > #So, here must be a method   myapi_deploy()
> > #Which will be called by acme.sh to deploy the cert
> > #returns 0 means success, otherwise error.
> >
> > . /etc/rc.conf
> >
> > ########  Public functions #####################
> >
> > #domain keyfile certfile cafile fullchain
> > astlinux_deploy() {
> >   _cdomain="$1"
> >   _ckey="$2"
> >   _ccert="$3"
> >   _cca="$4"
> >   _cfullchain="$5"
> >
> >   _debug _cdomain "$_cdomain"
> >   _debug _ckey "$_ckey"
> >   _debug _ccert "$_ccert"
> >   _debug _cca "$_cca"
> >   _debug _cfullchain "$_cfullchain"
> >
> >   if [ -n "$HTTPSCERT" ]; then
> >     service lighttpd stop
> >     cat "$_ckey" "$_ccert" > "$HTTPSCERT"
> >     if [ -n "$HTTPSCHAIN" ]; then
> >       cat "$_cfullchain" > "$HTTPSCHAIN"
> >     fi
> >     service lighttpd init
> >   fi
> >   return 0
> > }
> >
> > This takes care of lighttpd... but the deploy script could be expanded
> to handle SIP-TLS or other places that you want to use the same certificate.
> >
> > Now request a certificate...
> >
> > /etc/acme.sh/acme.sh --home /etc/acme.sh --issue -d yourdomain.tld -w
> /home/ftp/www -d pbx.youdomain.tld -d sip.yourdomain.tld
> >
> > You can add multiple domains with -d flag (all must be valid public URLs
> that can be validated as owned by you).
> > This assumes that HTTPDIR is /home/ftp/www (ideally we should wrap this
> in a script that gets it from $HTTPDIR)  and that port 80 is open...
> validating domains by DNS is for another day... this method gets me started.
> >
> > Now deploy the certificate...
> >
> > /etc/acme.sh/acme.sh --home /etc/acme.sh --deploy -d yourdomain.tld
> --deploy-hook astlinux
> >
> > Which runs the above astlinux.sh file we placed in /etc/acme.sh/deploy
> directory.  Note that the script does a stop / init on lighttpd because a
> restart would not be good enough (because the ca chain file might not exist
> when init is first run)
> >
> > Now whenever the certificate is renewed, the certificates are updated
> and the deploy script is run automatically.  This would be triggered by the
> cron job.
> >
> > If you start to play with this, be sure to add --test to all acme.sh
> commands during your testing.... to point it at a test server.  LetsEncrypt
> limits the number of times you can request/renew a certificate each week
> which you could easily hit during testing.  When ready to use a real
> certificate, --revoke the test ones and then --issue from non-test server.
> >
> > David
> >
> > On Wed, Jan 11, 2017 at 1:19 PM, Lonnie Abelbeck <
> li...@lo...> wrote:
> > Hi David,
> >
> > #2 solved, a good feature to have for completeness.  Specify in
> user.conf.
> >
> > https://sourceforge.net/p/astlinux/code/8089
> >
> > Lonnie
> >
> >
> > On Jan 10, 2017, at 10:40 PM, David Kerr <Da...@Ke...> wrote:
> >
> > > Tonights discoveries on this topic...
> > >
> > >       • Lighttpd loads certificates at startup only, so service will
> need to be stopped and started again each time the certificates are renewed
> (60 days).
> > >       • LetsEncrypt is issuing chained certificates, the intermediate
> certificates may not be included in browsers.  You therefore have to add
> the chain to the web server.  So lighttpd.conf needs a ssl.ca-file set in
> addition to ssl.pemfile.
> > >       • LetsEncrypt issues the cert and key as two separate files.
> The pem file that lighttpd needs has to be created each time the certs
> renew.
> > >       • the DNS registrar that I use (freeDNS) does not have an API to
> update TXT records.  Admin there suggests using POST to the subdomain web
> site... in other words need to create my own API !
> > > Nothing is ever easy, Huh?
> > >
> > > For #1 and #3... I will need to create a script to create the pem file
> and restart lighttpd. Should be easy enough.
> > > For #2... to maintain autogenerated lighttpd.conf file, need support
> for chain CA files added to the web interface (or recognize a variable we
> can set in user.conf, e.g. HTTPSCHAIN=/mnt/kd/ssl/mydomain.tld/fullchain.cer)
> and update /etc/init.d/lighttpd init() function to recognize it.
> > > For #4... more thinking to be done.
> > >
> > > David
>
> ------------------------------------------------------------
> ------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>

Great work David.

I'd suggest adding two lines, since HTTPSCERT includes a private key set mode 600, and add a sleep 1 to allow the stopping of lighttpd to settle down.
--
  if [ -n "$HTTPSCERT" ]; then
    service lighttpd stop
    cat "$_ckey" "$_ccert" > "$HTTPSCERT"
+  chmod 600 "$HTTPSCERT"
    if [ -n "$HTTPSCHAIN" ]; then
      cat "$_cfullchain" > "$HTTPSCHAIN"
    fi
+  sleep 1
    service lighttpd init
  fi
--

BTW, I independently spent a couple hours researching ACME clients and came to the same conclusion as you acme.sh  https://github.com/Neilpang/acme.sh is the best for AstLinux, and seems to be one of the only clients that supports DNS TXT validation.  Also pfSense has recently decided to use acme.sh as well.

acme.sh uses vanilla shell, curl and openssl as dependencies, perfect for us.

As you suggested David, we probably should add this to the build system ... a work in progress and disabled by default.

My thoughts on naming ...

package "acme"

/etc/acme -> /mnt/kd/acme/

/etc/ssl/acme -> /mnt/kd/ssl/acme/

Possibly Install into /stat/etc/acme/ and run under /mnt/kd/acme/ but this is looking tricky to do at build time as acme.sh --install tries to be "smart" and is more of a target method.

Hmmm, more thinking required ...  possibly we can set USER_PATH="/mnt/kd/acme" and act like IN_CRON=1 .

Lonnie


On Jan 11, 2017, at 9:10 PM, David Kerr <Da...@Ke...> wrote:

> Thanks Lonnie.  I now have a trusted certificate working for lighttpd HTTPS on AstLinux.  Here is what I did...
> 
> Add HTTPSCHAIN=/mnt/kd/ssl/https_ca_chain.pem to user.conf
> 
> Install acme.sh (see https://github.com/Neilpang/acme.sh) on my astlinux.  From ~ (root home)...
> 
> curl https://codeload.github.com/Neilpang/acme.sh/tar.gz/master > acme.sh-master.tar.gz
> tar xzf acme.sh-master.tar.gz
> cd acme.sh-master
> ./acme.sh --install --home /etc/acme.sh --accountemail "your@email.here" --useragent "AstLinux"
> 
> The process of installing should ideally be done as part of AstLinux build... we could add a package "letsencrypt" which gets acme.sh and places it into the right directory (I chose /etc/acme.sh).  Though the last part which sets account email would have to be done later.  Note that the install process adds a crontab as well which is needed for auto renew.
> 
> Add a script file...  /etc/acme.sh/deploy/astlinux.sh which contains the following (modeled on their template)...
> 
> #!/usr/bin/env bash
> 
> #Here is a sample custom api script.
> #This file name is "myapi.sh"
> #So, here must be a method   myapi_deploy()
> #Which will be called by acme.sh to deploy the cert
> #returns 0 means success, otherwise error.
> 
> . /etc/rc.conf
> 
> ########  Public functions #####################
> 
> #domain keyfile certfile cafile fullchain
> astlinux_deploy() {
>   _cdomain="$1"
>   _ckey="$2"
>   _ccert="$3"
>   _cca="$4"
>   _cfullchain="$5"
> 
>   _debug _cdomain "$_cdomain"
>   _debug _ckey "$_ckey"
>   _debug _ccert "$_ccert"
>   _debug _cca "$_cca"
>   _debug _cfullchain "$_cfullchain"
> 
>   if [ -n "$HTTPSCERT" ]; then
>     service lighttpd stop
>     cat "$_ckey" "$_ccert" > "$HTTPSCERT"
>     if [ -n "$HTTPSCHAIN" ]; then
>       cat "$_cfullchain" > "$HTTPSCHAIN"
>     fi
>     service lighttpd init
>   fi
>   return 0
> }
> 
> This takes care of lighttpd... but the deploy script could be expanded to handle SIP-TLS or other places that you want to use the same certificate.
> 
> Now request a certificate...
> 
> /etc/acme.sh/acme.sh --home /etc/acme.sh --issue -d yourdomain.tld -w /home/ftp/www -d pbx.youdomain.tld -d sip.yourdomain.tld
> 
> You can add multiple domains with -d flag (all must be valid public URLs that can be validated as owned by you).
> This assumes that HTTPDIR is /home/ftp/www (ideally we should wrap this in a script that gets it from $HTTPDIR)  and that port 80 is open... validating domains by DNS is for another day... this method gets me started.
> 
> Now deploy the certificate...
> 
> /etc/acme.sh/acme.sh --home /etc/acme.sh --deploy -d yourdomain.tld --deploy-hook astlinux
> 
> Which runs the above astlinux.sh file we placed in /etc/acme.sh/deploy directory.  Note that the script does a stop / init on lighttpd because a restart would not be good enough (because the ca chain file might not exist when init is first run)
> 
> Now whenever the certificate is renewed, the certificates are updated and the deploy script is run automatically.  This would be triggered by the cron job.
> 
> If you start to play with this, be sure to add --test to all acme.sh commands during your testing.... to point it at a test server.  LetsEncrypt limits the number of times you can request/renew a certificate each week which you could easily hit during testing.  When ready to use a real certificate, --revoke the test ones and then --issue from non-test server.
> 
> David
> 
> On Wed, Jan 11, 2017 at 1:19 PM, Lonnie Abelbeck <li...@lo...> wrote:
> Hi David,
> 
> #2 solved, a good feature to have for completeness.  Specify in user.conf.
> 
> https://sourceforge.net/p/astlinux/code/8089
> 
> Lonnie
> 
> 
> On Jan 10, 2017, at 10:40 PM, David Kerr <Da...@Ke...> wrote:
> 
> > Tonights discoveries on this topic...
> >
> >       • Lighttpd loads certificates at startup only, so service will need to be stopped and started again each time the certificates are renewed (60 days).
> >       • LetsEncrypt is issuing chained certificates, the intermediate certificates may not be included in browsers.  You therefore have to add the chain to the web server.  So lighttpd.conf needs a ssl.ca-file set in addition to ssl.pemfile.
> >       • LetsEncrypt issues the cert and key as two separate files.  The pem file that lighttpd needs has to be created each time the certs renew.
> >       • the DNS registrar that I use (freeDNS) does not have an API to update TXT records.  Admin there suggests using POST to the subdomain web site... in other words need to create my own API !
> > Nothing is ever easy, Huh?
> >
> > For #1 and #3... I will need to create a script to create the pem file and restart lighttpd. Should be easy enough.
> > For #2... to maintain autogenerated lighttpd.conf file, need support for chain CA files added to the web interface (or recognize a variable we can set in user.conf, e.g. HTTPSCHAIN=/mnt/kd/ssl/mydomain.tld/fullchain.cer) and update /etc/init.d/lighttpd init() function to recognize it.
> > For #4... more thinking to be done.
> >
> > David

Thanks Lonnie.  I now have a trusted certificate working for lighttpd HTTPS
on AstLinux.  Here is what I did...

Add HTTPSCHAIN=/mnt/kd/ssl/https_ca_chain.pem to user.conf

Install acme.sh (see https://github.com/Neilpang/acme.sh) on my astlinux.
>From ~ (root home)...

curl https://codeload.github.com/Neilpang/acme.sh/tar.gz/master >
acme.sh-master.tar.gz
tar xzf acme.sh-master.tar.gz
cd acme.sh-master
./acme.sh --install --home /etc/acme.sh --accountemail "your@email.here"
--useragent "AstLinux"


The process of installing should ideally be done as part of AstLinux
build... we could add a package "letsencrypt" which gets acme.sh and places
it into the right directory (I chose /etc/acme.sh).  Though the last part
which sets account email would have to be done later.  Note that the
install process adds a crontab as well which is needed for auto renew.

Add a script file...  /etc/acme.sh/deploy/astlinux.sh which contains the
following (modeled on their template)...

#!/usr/bin/env bash

#Here is a sample custom api script.
#This file name is "myapi.sh"
#So, here must be a method   myapi_deploy()
#Which will be called by acme.sh to deploy the cert
#returns 0 means success, otherwise error.

. /etc/rc.conf

########  Public functions #####################

#domain keyfile certfile cafile fullchain
astlinux_deploy() {
  _cdomain="$1"
  _ckey="$2"
  _ccert="$3"
  _cca="$4"
  _cfullchain="$5"

  _debug _cdomain "$_cdomain"
  _debug _ckey "$_ckey"
  _debug _ccert "$_ccert"
  _debug _cca "$_cca"
  _debug _cfullchain "$_cfullchain"

  if [ -n "$HTTPSCERT" ]; then
    service lighttpd stop
    cat "$_ckey" "$_ccert" > "$HTTPSCERT"
    if [ -n "$HTTPSCHAIN" ]; then
      cat "$_cfullchain" > "$HTTPSCHAIN"
    fi
    service lighttpd init
  fi
  return 0
}


This takes care of lighttpd... but the deploy script could be expanded to
handle SIP-TLS or other places that you want to use the same certificate.

Now request a certificate...

/etc/acme.sh/acme.sh --home /etc/acme.sh --issue -d yourdomain.tld -w
/home/ftp/www -d pbx.youdomain.tld -d sip.yourdomain.tld


You can add multiple domains with -d flag (all must be valid public URLs
that can be validated as owned by you).
This assumes that HTTPDIR is /home/ftp/www (ideally we should wrap this in
a script that gets it from $HTTPDIR)  and that port 80 is open...
validating domains by DNS is for another day... this method gets me started.

Now deploy the certificate...

/etc/acme.sh/acme.sh --home /etc/acme.sh --deploy -d yourdomain.tld
--deploy-hook astlinux


Which runs the above astlinux.sh file we placed in /etc/acme.sh/deploy
directory.  Note that the script does a stop / init on lighttpd because a
restart would not be good enough (because the ca chain file might not exist
when init is first run)

Now whenever the certificate is renewed, the certificates are updated and
the deploy script is run automatically.  This would be triggered by the
cron job.

If you start to play with this, be sure to add --test to all acme.sh
commands during your testing.... to point it at a test server.  LetsEncrypt
limits the number of times you can request/renew a certificate each week
which you could easily hit during testing.  When ready to use a real
certificate, --revoke the test ones and then --issue from non-test server.

David























On Wed, Jan 11, 2017 at 1:19 PM, Lonnie Abelbeck <li...@lo...>
wrote:

> Hi David,
>
> #2 solved, a good feature to have for completeness.  Specify in user.conf.
>
> https://sourceforge.net/p/astlinux/code/8089
>
> Lonnie
>
>
> On Jan 10, 2017, at 10:40 PM, David Kerr <Da...@Ke...> wrote:
>
> > Tonights discoveries on this topic...
> >
> >       • Lighttpd loads certificates at startup only, so service will
> need to be stopped and started again each time the certificates are renewed
> (60 days).
> >       • LetsEncrypt is issuing chained certificates, the intermediate
> certificates may not be included in browsers.  You therefore have to add
> the chain to the web server.  So lighttpd.conf needs a ssl.ca-file set in
> addition to ssl.pemfile.
> >       • LetsEncrypt issues the cert and key as two separate files.  The
> pem file that lighttpd needs has to be created each time the certs renew.
> >       • the DNS registrar that I use (freeDNS) does not have an API to
> update TXT records.  Admin there suggests using POST to the subdomain web
> site... in other words need to create my own API !
> > Nothing is ever easy, Huh?
> >
> > For #1 and #3... I will need to create a script to create the pem file
> and restart lighttpd. Should be easy enough.
> > For #2... to maintain autogenerated lighttpd.conf file, need support for
> chain CA files added to the web interface (or recognize a variable we can
> set in user.conf, e.g. HTTPSCHAIN=/mnt/kd/ssl/mydomain.tld/fullchain.cer)
> and update /etc/init.d/lighttpd init() function to recognize it.
> > For #4... more thinking to be done.
> >
> > David
> >
> >
> > On Tue, Jan 10, 2017 at 10:49 AM, Lonnie Abelbeck <
> li...@lo...> wrote:
> > Thanks David for answering my question, makes total sense that each DNS
> name must be independently challenged and validated.
> >
> > > I'm not sure I understand your point about connecting to HTTPS on a
> local isolated (no public internet connection) network.
> >
> > I was wrong, I now see the intermediate "Let's Encrypt Authority X3"
> cert is installed on the server and cross-signed with "DST Root CA X3" for
> root CA compatibility.
> >
> > Chain of Trust
> > https://letsencrypt.org/certificates/
> >
> > The browser's CRL / OCSP check would fail (with no internet), but I
> think that is out of band and not critical to the initial certificate check.
> >
> >
> > > So for AstLinux it feels like the DNS TXT record method might be
> better.
> >
> > I'm thinking the same that using a DNS Challenge is the best method for
> AstLinux.
> >
> >
> > Lonnie
> >
> >
> > On Jan 9, 2017, at 9:58 PM, David Kerr <Da...@Ke...> wrote:
> >
> > > Thanks Lonnie....
> > >
> > > LetsEcrypt can issue a single certificate for multiple domain names,
> so you can request for www.example.tld, sip.example.tld and
> xmpp.example.tld all in the one request and it will issue a single
> certificate valid for all.  However, LetsEncrypt is going to validate that
> you own each of these domain names by sending a request to each.  So
> 1.2.3.4 will get one validation request and 4.3.2.1 will get two separate
> validation requests.  Each must respond to either the HTTP or DNS
> validation methods.  You could redirect the HTTP requests to 4.3.2.1 on to
> 1.2.3.4 and have it do the work to verify, but that still requires that
> 4.3.2.1 has port 80 open to redirect it. I personally don't think it is a
> good idea to have one certificate for two separate public IP servers, fine
> for multiple services (say sip and xmpp) at the same IP.
> > >
> > > I'm not sure I understand your point about connecting to HTTPS on a
> local isolated (no public internet connection) network.  Browsers should
> still be able to connect as the root certificate for LetsEncrypt (ISRG Root
> X1) is embedded into most recent browsers so I don't think it needs to go
> out to public internet to validate the certs?
> > >
> > > David
> > >
> > >
> > >
> > > On Mon, Jan 9, 2017 at 4:35 PM, Lonnie Abelbeck <
> li...@lo...> wrote:
> > > David, Excellent synopsis.
> > >
> > > As for what is useful with AstLinux, I think SIP-TLS and XMPP are good
> candidates for LetsEncrypt certs, but in general not much else IMHO.
> > >
> > > For the HTTPS case, I have found storing self signed cert exceptions
> in browsers simple, and unless major changes in browsers occur, they
> display as a trusted site.
> > >
> > > In an appliance like AstLinux, managing via HTTPS is occasionally done
> locally without an active internet connection, using publicly signed certs
> would be a problem in that case.  Additionally a split-horison DNS can be
> setup in AstLinux which could be an issue matching the cert's "Subject
> Alternative Name" DNS Name's.
> > >
> > > In our case for OpenVPN and IPsec, passing out the self-signed CA is
> not a big deal for a few VPN clients.  If you were running a campus of VPN
> clients that would be different.
> > >
> > >
> > > A question.  Say you want a LetsEncrypt cert for www.example.tld (A
> record 1.2.3.4, public HTTP server) , sip.example.tld and xmpp.example.tld
> (both, A record 4.3.2.1, AstLinux public IP).  Could a LetsEncrypt cert be
> generated for all three DNS Names only using a HTTP server at 1.2.3.4 ?  If
> so, the LetsEncrypt cert could be generated and renewed remotely and
> AstLinux could keep it's copies in sync with the remote server.
> > >
> > > Lonnie
> > >
> > >
> > >
> > > On Jan 9, 2017, at 11:40 AM, David Kerr <Da...@Ke...> wrote:
> > >
> > > > Devs,
> > > >   One of the things that has been bugging me for a while is that
> AstLinux HTTPS self signed certificates are not trusted by browsers.  I
> would really like to have AstLinux use trusted certificates but until
> recently that has meant paying real $$$'s to a CA.
> > > >
> > > > A couple of years ago a non-profit org was set up, LetsEncrypt.org,
> to remove this barrier and encourage everyone to use HTTPS for their web
> servers.  It has now matured to a point where it might make sense to adopt
> it in AstLinux.
> > > >
> > > > I have been investigating how easy it would be to have AstLinux use
> trusted certificates from LetsEncrypt.  Here is an initial analysis...
> > > >
> > > > Before LetsEncrypt will issue you a certificate it has to validate
> that you are who you say you are.  So if you ask for a certificate for
> example.com then it needs to ensure that your really are example.com.
> There are a couple of options for this.  First it does a DNS lookup on
> example.com and then either...
> > > >
> > > >       • Uses HTTP to example.com with challenge/response that
> validates that you own the webserver at example.com.  It will ONLY do
> this over port 80 (or 443, but that is catch 22).  There are many requests
> online that they support another port but ostensibly for security reasons
> they refuse to do that.  Pressure is building on them, but so far no change.
> > > >       • Uses a TXT record at your DNS registrar... it asks the
> client (certbot/acme/dehydrated/whatever) to add a TXT record to the
> example.com DNS server entries then it validates that the TXT entry is
> indeed there.  Then client is asked to delete the TXT record.
> > > > It does not perform validation every time you request a
> certificate... if you are already validated then it can skip that part of
> the process.  I do not know how often it needs to revalidate, but I assume
> that on certificate expiration it will revalidate when you ask for a renew
> (certs are valid for 90 days, they recommend renew at 60 days).
> > > >
> > > > The simplest is the HTTP method and is what I used for testing.
> But...
> > > >       • AstLinux is a router.  If port 80 is NAT forwarded then it
> won't work.
> > > >       • If you don't have port 80 open (firewall blocked) then it
> won't work.
> > > >       • They don't publish their IP addresses so you cannot add
> firewall rule just for them (and they state that their IPs may change or
> they may use multiple servers at their end so don't rely on that).
> > > >       • You can have lighttpd special handle the request from
> LetsEncrypt and redirect it.  But of course requires port 80 to be open.
> > > > For one-off issuing of the certificate we could probably live with
> temporarily opening port 80 and/or adjusting firewall rules but doing this
> automatically every 60 days may become problematic.  I need to give more
> thought to this.
> > > >
> > > > So for AstLinux it feels like the DNS TXT record method might be
> better.  The acme.sh client (which is what I used for testing...
> https://github.com/Neilpang/acme.sh)has support for several DNS services
> and you can add support yourself for those not provided (and presumably
> contribute back).  The service I use (freedns.afraid.org) is not yet
> among the ones acme.sh support.  Nor is google domains.  So I have not
> tested this method yet.
> > > >
> > > > I have not looked at other clients but acme.sh seems to be a pretty
> solid one.  Their "official" client, certbot, looked more complicated than
> I wanted to deal with for testing purposes.
> > > >
> > > > Would love to get folks opinion on this topic and thoughts on how
> best to implement.
> > > >
> > > > David
> > > >
> > > > ------------------------------------------------------------
> ------------------
> > > > Developer Access Program for Intel Xeon Phi Processors
> > > > Access to Intel Xeon Phi processor-based developer platforms.
> > > > With one year of Intel Parallel Studio XE.
> > > > Training and support from Colfax.
> > > > Order your platform today. http://sdm.link/xeonphi_______
> ________________________________________
> > > > Astlinux-devel mailing list
> > > > Ast...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > > >
> > > > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
> > >
> > >
> > > ------------------------------------------------------------
> ------------------
> > > Developer Access Program for Intel Xeon Phi Processors
> > > Access to Intel Xeon Phi processor-based developer platforms.
> > > With one year of Intel Parallel Studio XE.
> > > Training and support from Colfax.
> > > Order your platform today. http://sdm.link/xeonphi
> > > _______________________________________________
> > > Astlinux-devel mailing list
> > > Ast...@li...
> > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > >
> > > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
> > >
> > > ------------------------------------------------------------
> ------------------
> > > Developer Access Program for Intel Xeon Phi Processors
> > > Access to Intel Xeon Phi processor-based developer platforms.
> > > With one year of Intel Parallel Studio XE.
> > > Training and support from Colfax.
> > > Order your platform today. http://sdm.link/xeonphi_______
> ________________________________________
> > > Astlinux-devel mailing list
> > > Ast...@li...
> > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > >
> > > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
> >
> >
> > ------------------------------------------------------------
> ------------------
> > Developer Access Program for Intel Xeon Phi Processors
> > Access to Intel Xeon Phi processor-based developer platforms.
> > With one year of Intel Parallel Studio XE.
> > Training and support from Colfax.
> > Order your platform today. http://sdm.link/xeonphi
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
> >
> > ------------------------------------------------------------
> ------------------
> > Developer Access Program for Intel Xeon Phi Processors
> > Access to Intel Xeon Phi processor-based developer platforms.
> > With one year of Intel Parallel Studio XE.
> > Training and support from Colfax.
> > Order your platform today. http://sdm.link/xeonphi_______
> ________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>
>
> ------------------------------------------------------------
> ------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>

On Jan 11, 2017, at 12:54 PM, Michael Keuter <li...@mk...> wrote:

> 
>> Am 11.01.2017 um 05:40 schrieb David Kerr <da...@ke...>:
>> 
>> Tonights discoveries on this topic...
>> 
>> 	• Lighttpd loads certificates at startup only, so service will need to be stopped and started again each time the certificates are renewed (60 days).
> 
> In about 20% of the cases when I restarted lighttpd per CLI, Asterisk was stopped afterwards for some reasons (without any log). Just FYI to keep an eye on.

Hi Michael,

I recall you mentioning this before, but I have not see it.  Running this test script:
--
while true; do
service lighttpd restart
asterisk -rx "core show version"
if [ $? -ne 0 ]; then
  echo "Asterisk stopped"
  break
fi
sleep 10
done
--

I let it run 100+ iterations without any mysterious Asterisk stops.

Possibly you have some Monit checks/actions that is causing the problem.

Lonnie

> Am 11.01.2017 um 05:40 schrieb David Kerr <da...@ke...>:
> 
> Tonights discoveries on this topic...
> 
> 	• Lighttpd loads certificates at startup only, so service will need to be stopped and started again each time the certificates are renewed (60 days).

In about 20% of the cases when I restarted lighttpd per CLI, Asterisk was stopped afterwards for some reasons (without any log). Just FYI to keep an eye on.

> 	• LetsEncrypt is issuing chained certificates, the intermediate certificates may not be included in browsers.  You therefore have to add the chain to the web server.  So lighttpd.conf needs a ssl.ca-file set in addition to ssl.pemfile.
> 	• LetsEncrypt issues the cert and key as two separate files.  The pem file that lighttpd needs has to be created each time the certs renew.
> 	• the DNS registrar that I use (freeDNS) does not have an API to update TXT records.  Admin there suggests using POST to the subdomain web site... in other words need to create my own API !
> Nothing is ever easy, Huh?
> 
> For #1 and #3... I will need to create a script to create the pem file and restart lighttpd. Should be easy enough.
> For #2... to maintain autogenerated lighttpd.conf file, need support for chain CA files added to the web interface (or recognize a variable we can set in user.conf, e.g. HTTPSCHAIN=/mnt/kd/ssl/mydomain.tld/fullchain.cer) and update /etc/init.d/lighttpd init() function to recognize it.
> For #4... more thinking to be done.
> 
> David
> 
> 
> On Tue, Jan 10, 2017 at 10:49 AM, Lonnie Abelbeck <li...@lo...> wrote:
> Thanks David for answering my question, makes total sense that each DNS name must be independently challenged and validated.
> 
> > I'm not sure I understand your point about connecting to HTTPS on a local isolated (no public internet connection) network.
> 
> I was wrong, I now see the intermediate "Let's Encrypt Authority X3" cert is installed on the server and cross-signed with "DST Root CA X3" for root CA compatibility.
> 
> Chain of Trust
> https://letsencrypt.org/certificates/
> 
> The browser's CRL / OCSP check would fail (with no internet), but I think that is out of band and not critical to the initial certificate check.
> 
> 
> > So for AstLinux it feels like the DNS TXT record method might be better.
> 
> I'm thinking the same that using a DNS Challenge is the best method for AstLinux.
> 
> 
> Lonnie
> 
> 
> On Jan 9, 2017, at 9:58 PM, David Kerr <Da...@Ke...> wrote:
> 
> > Thanks Lonnie....
> >
> > LetsEcrypt can issue a single certificate for multiple domain names, so you can request for www.example.tld, sip.example.tld and xmpp.example.tld all in the one request and it will issue a single certificate valid for all.  However, LetsEncrypt is going to validate that you own each of these domain names by sending a request to each.  So 1.2.3.4 will get one validation request and 4.3.2.1 will get two separate validation requests.  Each must respond to either the HTTP or DNS validation methods.  You could redirect the HTTP requests to 4.3.2.1 on to 1.2.3.4 and have it do the work to verify, but that still requires that 4.3.2.1 has port 80 open to redirect it. I personally don't think it is a good idea to have one certificate for two separate public IP servers, fine for multiple services (say sip and xmpp) at the same IP.
> >
> > I'm not sure I understand your point about connecting to HTTPS on a local isolated (no public internet connection) network.  Browsers should still be able to connect as the root certificate for LetsEncrypt (ISRG Root X1) is embedded into most recent browsers so I don't think it needs to go out to public internet to validate the certs?
> >
> > David
> >
> >
> >
> > On Mon, Jan 9, 2017 at 4:35 PM, Lonnie Abelbeck <li...@lo...> wrote:
> > David, Excellent synopsis.
> >
> > As for what is useful with AstLinux, I think SIP-TLS and XMPP are good candidates for LetsEncrypt certs, but in general not much else IMHO.
> >
> > For the HTTPS case, I have found storing self signed cert exceptions in browsers simple, and unless major changes in browsers occur, they display as a trusted site.
> >
> > In an appliance like AstLinux, managing via HTTPS is occasionally done locally without an active internet connection, using publicly signed certs would be a problem in that case.  Additionally a split-horison DNS can be setup in AstLinux which could be an issue matching the cert's "Subject Alternative Name" DNS Name's.
> >
> > In our case for OpenVPN and IPsec, passing out the self-signed CA is not a big deal for a few VPN clients.  If you were running a campus of VPN clients that would be different.
> >
> >
> > A question.  Say you want a LetsEncrypt cert for www.example.tld (A record 1.2.3.4, public HTTP server) , sip.example.tld and xmpp.example.tld (both, A record 4.3.2.1, AstLinux public IP).  Could a LetsEncrypt cert be generated for all three DNS Names only using a HTTP server at 1.2.3.4 ?  If so, the LetsEncrypt cert could be generated and renewed remotely and AstLinux could keep it's copies in sync with the remote server.
> >
> > Lonnie
> >
> >
> >
> > On Jan 9, 2017, at 11:40 AM, David Kerr <Da...@Ke...> wrote:
> >
> > > Devs,
> > >   One of the things that has been bugging me for a while is that AstLinux HTTPS self signed certificates are not trusted by browsers.  I would really like to have AstLinux use trusted certificates but until recently that has meant paying real $$$'s to a CA.
> > >
> > > A couple of years ago a non-profit org was set up, LetsEncrypt.org, to remove this barrier and encourage everyone to use HTTPS for their web servers.  It has now matured to a point where it might make sense to adopt it in AstLinux.
> > >
> > > I have been investigating how easy it would be to have AstLinux use trusted certificates from LetsEncrypt.  Here is an initial analysis...
> > >
> > > Before LetsEncrypt will issue you a certificate it has to validate that you are who you say you are.  So if you ask for a certificate for example.com then it needs to ensure that your really are example.com.  There are a couple of options for this.  First it does a DNS lookup on example.com and then either...
> > >
> > >       • Uses HTTP to example.com with challenge/response that validates that you own the webserver at example.com.  It will ONLY do this over port 80 (or 443, but that is catch 22).  There are many requests online that they support another port but ostensibly for security reasons they refuse to do that.  Pressure is building on them, but so far no change.
> > >       • Uses a TXT record at your DNS registrar... it asks the client (certbot/acme/dehydrated/whatever) to add a TXT record to the example.com DNS server entries then it validates that the TXT entry is indeed there.  Then client is asked to delete the TXT record.
> > > It does not perform validation every time you request a certificate... if you are already validated then it can skip that part of the process.  I do not know how often it needs to revalidate, but I assume that on certificate expiration it will revalidate when you ask for a renew (certs are valid for 90 days, they recommend renew at 60 days).
> > >
> > > The simplest is the HTTP method and is what I used for testing.  But...
> > >       • AstLinux is a router.  If port 80 is NAT forwarded then it won't work.
> > >       • If you don't have port 80 open (firewall blocked) then it won't work.
> > >       • They don't publish their IP addresses so you cannot add firewall rule just for them (and they state that their IPs may change or they may use multiple servers at their end so don't rely on that).
> > >       • You can have lighttpd special handle the request from LetsEncrypt and redirect it.  But of course requires port 80 to be open.
> > > For one-off issuing of the certificate we could probably live with temporarily opening port 80 and/or adjusting firewall rules but doing this automatically every 60 days may become problematic.  I need to give more thought to this.
> > >
> > > So for AstLinux it feels like the DNS TXT record method might be better.  The acme.sh client (which is what I used for testing... https://github.com/Neilpang/acme.sh)has support for several DNS services and you can add support yourself for those not provided (and presumably contribute back).  The service I use (freedns.afraid.org) is not yet among the ones acme.sh support.  Nor is google domains.  So I have not tested this method yet.
> > >
> > > I have not looked at other clients but acme.sh seems to be a pretty solid one.  Their "official" client, certbot, looked more complicated than I wanted to deal with for testing purposes.
> > >
> > > Would love to get folks opinion on this topic and thoughts on how best to implement.
> > >
> > > David

Michael

http://www.mksolutions.info

Hi David,

#2 solved, a good feature to have for completeness.  Specify in user.conf.

https://sourceforge.net/p/astlinux/code/8089

Lonnie


On Jan 10, 2017, at 10:40 PM, David Kerr <Da...@Ke...> wrote:

> Tonights discoveries on this topic...
> 
> 	• Lighttpd loads certificates at startup only, so service will need to be stopped and started again each time the certificates are renewed (60 days).
> 	• LetsEncrypt is issuing chained certificates, the intermediate certificates may not be included in browsers.  You therefore have to add the chain to the web server.  So lighttpd.conf needs a ssl.ca-file set in addition to ssl.pemfile.
> 	• LetsEncrypt issues the cert and key as two separate files.  The pem file that lighttpd needs has to be created each time the certs renew.
> 	• the DNS registrar that I use (freeDNS) does not have an API to update TXT records.  Admin there suggests using POST to the subdomain web site... in other words need to create my own API !
> Nothing is ever easy, Huh?
> 
> For #1 and #3... I will need to create a script to create the pem file and restart lighttpd. Should be easy enough.
> For #2... to maintain autogenerated lighttpd.conf file, need support for chain CA files added to the web interface (or recognize a variable we can set in user.conf, e.g. HTTPSCHAIN=/mnt/kd/ssl/mydomain.tld/fullchain.cer) and update /etc/init.d/lighttpd init() function to recognize it.
> For #4... more thinking to be done.
> 
> David
> 
> 
> On Tue, Jan 10, 2017 at 10:49 AM, Lonnie Abelbeck <li...@lo...> wrote:
> Thanks David for answering my question, makes total sense that each DNS name must be independently challenged and validated.
> 
> > I'm not sure I understand your point about connecting to HTTPS on a local isolated (no public internet connection) network.
> 
> I was wrong, I now see the intermediate "Let's Encrypt Authority X3" cert is installed on the server and cross-signed with "DST Root CA X3" for root CA compatibility.
> 
> Chain of Trust
> https://letsencrypt.org/certificates/
> 
> The browser's CRL / OCSP check would fail (with no internet), but I think that is out of band and not critical to the initial certificate check.
> 
> 
> > So for AstLinux it feels like the DNS TXT record method might be better.
> 
> I'm thinking the same that using a DNS Challenge is the best method for AstLinux.
> 
> 
> Lonnie
> 
> 
> On Jan 9, 2017, at 9:58 PM, David Kerr <Da...@Ke...> wrote:
> 
> > Thanks Lonnie....
> >
> > LetsEcrypt can issue a single certificate for multiple domain names, so you can request for www.example.tld, sip.example.tld and xmpp.example.tld all in the one request and it will issue a single certificate valid for all.  However, LetsEncrypt is going to validate that you own each of these domain names by sending a request to each.  So 1.2.3.4 will get one validation request and 4.3.2.1 will get two separate validation requests.  Each must respond to either the HTTP or DNS validation methods.  You could redirect the HTTP requests to 4.3.2.1 on to 1.2.3.4 and have it do the work to verify, but that still requires that 4.3.2.1 has port 80 open to redirect it. I personally don't think it is a good idea to have one certificate for two separate public IP servers, fine for multiple services (say sip and xmpp) at the same IP.
> >
> > I'm not sure I understand your point about connecting to HTTPS on a local isolated (no public internet connection) network.  Browsers should still be able to connect as the root certificate for LetsEncrypt (ISRG Root X1) is embedded into most recent browsers so I don't think it needs to go out to public internet to validate the certs?
> >
> > David
> >
> >
> >
> > On Mon, Jan 9, 2017 at 4:35 PM, Lonnie Abelbeck <li...@lo...> wrote:
> > David, Excellent synopsis.
> >
> > As for what is useful with AstLinux, I think SIP-TLS and XMPP are good candidates for LetsEncrypt certs, but in general not much else IMHO.
> >
> > For the HTTPS case, I have found storing self signed cert exceptions in browsers simple, and unless major changes in browsers occur, they display as a trusted site.
> >
> > In an appliance like AstLinux, managing via HTTPS is occasionally done locally without an active internet connection, using publicly signed certs would be a problem in that case.  Additionally a split-horison DNS can be setup in AstLinux which could be an issue matching the cert's "Subject Alternative Name" DNS Name's.
> >
> > In our case for OpenVPN and IPsec, passing out the self-signed CA is not a big deal for a few VPN clients.  If you were running a campus of VPN clients that would be different.
> >
> >
> > A question.  Say you want a LetsEncrypt cert for www.example.tld (A record 1.2.3.4, public HTTP server) , sip.example.tld and xmpp.example.tld (both, A record 4.3.2.1, AstLinux public IP).  Could a LetsEncrypt cert be generated for all three DNS Names only using a HTTP server at 1.2.3.4 ?  If so, the LetsEncrypt cert could be generated and renewed remotely and AstLinux could keep it's copies in sync with the remote server.
> >
> > Lonnie
> >
> >
> >
> > On Jan 9, 2017, at 11:40 AM, David Kerr <Da...@Ke...> wrote:
> >
> > > Devs,
> > >   One of the things that has been bugging me for a while is that AstLinux HTTPS self signed certificates are not trusted by browsers.  I would really like to have AstLinux use trusted certificates but until recently that has meant paying real $$$'s to a CA.
> > >
> > > A couple of years ago a non-profit org was set up, LetsEncrypt.org, to remove this barrier and encourage everyone to use HTTPS for their web servers.  It has now matured to a point where it might make sense to adopt it in AstLinux.
> > >
> > > I have been investigating how easy it would be to have AstLinux use trusted certificates from LetsEncrypt.  Here is an initial analysis...
> > >
> > > Before LetsEncrypt will issue you a certificate it has to validate that you are who you say you are.  So if you ask for a certificate for example.com then it needs to ensure that your really are example.com.  There are a couple of options for this.  First it does a DNS lookup on example.com and then either...
> > >
> > >       • Uses HTTP to example.com with challenge/response that validates that you own the webserver at example.com.  It will ONLY do this over port 80 (or 443, but that is catch 22).  There are many requests online that they support another port but ostensibly for security reasons they refuse to do that.  Pressure is building on them, but so far no change.
> > >       • Uses a TXT record at your DNS registrar... it asks the client (certbot/acme/dehydrated/whatever) to add a TXT record to the example.com DNS server entries then it validates that the TXT entry is indeed there.  Then client is asked to delete the TXT record.
> > > It does not perform validation every time you request a certificate... if you are already validated then it can skip that part of the process.  I do not know how often it needs to revalidate, but I assume that on certificate expiration it will revalidate when you ask for a renew (certs are valid for 90 days, they recommend renew at 60 days).
> > >
> > > The simplest is the HTTP method and is what I used for testing.  But...
> > >       • AstLinux is a router.  If port 80 is NAT forwarded then it won't work.
> > >       • If you don't have port 80 open (firewall blocked) then it won't work.
> > >       • They don't publish their IP addresses so you cannot add firewall rule just for them (and they state that their IPs may change or they may use multiple servers at their end so don't rely on that).
> > >       • You can have lighttpd special handle the request from LetsEncrypt and redirect it.  But of course requires port 80 to be open.
> > > For one-off issuing of the certificate we could probably live with temporarily opening port 80 and/or adjusting firewall rules but doing this automatically every 60 days may become problematic.  I need to give more thought to this.
> > >
> > > So for AstLinux it feels like the DNS TXT record method might be better.  The acme.sh client (which is what I used for testing... https://github.com/Neilpang/acme.sh)has support for several DNS services and you can add support yourself for those not provided (and presumably contribute back).  The service I use (freedns.afraid.org) is not yet among the ones acme.sh support.  Nor is google domains.  So I have not tested this method yet.
> > >
> > > I have not looked at other clients but acme.sh seems to be a pretty solid one.  Their "official" client, certbot, looked more complicated than I wanted to deal with for testing purposes.
> > >
> > > Would love to get folks opinion on this topic and thoughts on how best to implement.
> > >
> > > David
> > >
> > > ------------------------------------------------------------------------------
> > > Developer Access Program for Intel Xeon Phi Processors
> > > Access to Intel Xeon Phi processor-based developer platforms.
> > > With one year of Intel Parallel Studio XE.
> > > Training and support from Colfax.
> > > Order your platform today. http://sdm.link/xeonphi_______________________________________________
> > > Astlinux-devel mailing list
> > > Ast...@li...
> > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > >
> > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> >
> >
> > ------------------------------------------------------------------------------
> > Developer Access Program for Intel Xeon Phi Processors
> > Access to Intel Xeon Phi processor-based developer platforms.
> > With one year of Intel Parallel Studio XE.
> > Training and support from Colfax.
> > Order your platform today. http://sdm.link/xeonphi
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> >
> > ------------------------------------------------------------------------------
> > Developer Access Program for Intel Xeon Phi Processors
> > Access to Intel Xeon Phi processor-based developer platforms.
> > With one year of Intel Parallel Studio XE.
> > Training and support from Colfax.
> > Order your platform today. http://sdm.link/xeonphi_______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi_______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Tonights discoveries on this topic...


   1. Lighttpd loads certificates at startup only, so service will need to
   be stopped and started again each time the certificates are renewed (60
   days).
   2. LetsEncrypt is issuing chained certificates, the intermediate
   certificates may not be included in browsers.  You therefore have to add
   the chain to the web server.  So lighttpd.conf needs a ssl.ca-file set in
   addition to ssl.pemfile.
   3. LetsEncrypt issues the cert and key as two separate files.  The pem
   file that lighttpd needs has to be created each time the certs renew.
   4. the DNS registrar that I use (freeDNS) does not have an API to update
   TXT records.  Admin there suggests using POST to the subdomain web site...
   in other words need to create my own API !

Nothing is ever easy, Huh?

For #1 and #3... I will need to create a script to create the pem file and
restart lighttpd. Should be easy enough.
For #2... to maintain autogenerated lighttpd.conf file, need support for
chain CA files added to the web interface (or recognize a variable we can
set in user.conf, e.g. HTTPSCHAIN=/mnt/kd/ssl/mydomain.tld/fullchain.cer)
and update /etc/init.d/lighttpd init() function to recognize it.
For #4... more thinking to be done.

David


On Tue, Jan 10, 2017 at 10:49 AM, Lonnie Abelbeck <li...@lo...
> wrote:

> Thanks David for answering my question, makes total sense that each DNS
> name must be independently challenged and validated.
>
> > I'm not sure I understand your point about connecting to HTTPS on a
> local isolated (no public internet connection) network.
>
> I was wrong, I now see the intermediate "Let's Encrypt Authority X3" cert
> is installed on the server and cross-signed with "DST Root CA X3" for root
> CA compatibility.
>
> Chain of Trust
> https://letsencrypt.org/certificates/
>
> The browser's CRL / OCSP check would fail (with no internet), but I think
> that is out of band and not critical to the initial certificate check.
>
>
> > So for AstLinux it feels like the DNS TXT record method might be better.
>
> I'm thinking the same that using a DNS Challenge is the best method for
> AstLinux.
>
>
> Lonnie
>
>
> On Jan 9, 2017, at 9:58 PM, David Kerr <Da...@Ke...> wrote:
>
> > Thanks Lonnie....
> >
> > LetsEcrypt can issue a single certificate for multiple domain names, so
> you can request for www.example.tld, sip.example.tld and xmpp.example.tld
> all in the one request and it will issue a single certificate valid for
> all.  However, LetsEncrypt is going to validate that you own each of these
> domain names by sending a request to each.  So 1.2.3.4 will get one
> validation request and 4.3.2.1 will get two separate validation requests.
> Each must respond to either the HTTP or DNS validation methods.  You could
> redirect the HTTP requests to 4.3.2.1 on to 1.2.3.4 and have it do the work
> to verify, but that still requires that 4.3.2.1 has port 80 open to
> redirect it. I personally don't think it is a good idea to have one
> certificate for two separate public IP servers, fine for multiple services
> (say sip and xmpp) at the same IP.
> >
> > I'm not sure I understand your point about connecting to HTTPS on a
> local isolated (no public internet connection) network.  Browsers should
> still be able to connect as the root certificate for LetsEncrypt (ISRG Root
> X1) is embedded into most recent browsers so I don't think it needs to go
> out to public internet to validate the certs?
> >
> > David
> >
> >
> >
> > On Mon, Jan 9, 2017 at 4:35 PM, Lonnie Abelbeck <
> li...@lo...> wrote:
> > David, Excellent synopsis.
> >
> > As for what is useful with AstLinux, I think SIP-TLS and XMPP are good
> candidates for LetsEncrypt certs, but in general not much else IMHO.
> >
> > For the HTTPS case, I have found storing self signed cert exceptions in
> browsers simple, and unless major changes in browsers occur, they display
> as a trusted site.
> >
> > In an appliance like AstLinux, managing via HTTPS is occasionally done
> locally without an active internet connection, using publicly signed certs
> would be a problem in that case.  Additionally a split-horison DNS can be
> setup in AstLinux which could be an issue matching the cert's "Subject
> Alternative Name" DNS Name's.
> >
> > In our case for OpenVPN and IPsec, passing out the self-signed CA is not
> a big deal for a few VPN clients.  If you were running a campus of VPN
> clients that would be different.
> >
> >
> > A question.  Say you want a LetsEncrypt cert for www.example.tld (A
> record 1.2.3.4, public HTTP server) , sip.example.tld and xmpp.example.tld
> (both, A record 4.3.2.1, AstLinux public IP).  Could a LetsEncrypt cert be
> generated for all three DNS Names only using a HTTP server at 1.2.3.4 ?  If
> so, the LetsEncrypt cert could be generated and renewed remotely and
> AstLinux could keep it's copies in sync with the remote server.
> >
> > Lonnie
> >
> >
> >
> > On Jan 9, 2017, at 11:40 AM, David Kerr <Da...@Ke...> wrote:
> >
> > > Devs,
> > >   One of the things that has been bugging me for a while is that
> AstLinux HTTPS self signed certificates are not trusted by browsers.  I
> would really like to have AstLinux use trusted certificates but until
> recently that has meant paying real $$$'s to a CA.
> > >
> > > A couple of years ago a non-profit org was set up, LetsEncrypt.org, to
> remove this barrier and encourage everyone to use HTTPS for their web
> servers.  It has now matured to a point where it might make sense to adopt
> it in AstLinux.
> > >
> > > I have been investigating how easy it would be to have AstLinux use
> trusted certificates from LetsEncrypt.  Here is an initial analysis...
> > >
> > > Before LetsEncrypt will issue you a certificate it has to validate
> that you are who you say you are.  So if you ask for a certificate for
> example.com then it needs to ensure that your really are example.com.
> There are a couple of options for this.  First it does a DNS lookup on
> example.com and then either...
> > >
> > >       • Uses HTTP to example.com with challenge/response that
> validates that you own the webserver at example.com.  It will ONLY do
> this over port 80 (or 443, but that is catch 22).  There are many requests
> online that they support another port but ostensibly for security reasons
> they refuse to do that.  Pressure is building on them, but so far no change.
> > >       • Uses a TXT record at your DNS registrar... it asks the client
> (certbot/acme/dehydrated/whatever) to add a TXT record to the example.com
> DNS server entries then it validates that the TXT entry is indeed there.
> Then client is asked to delete the TXT record.
> > > It does not perform validation every time you request a certificate...
> if you are already validated then it can skip that part of the process.  I
> do not know how often it needs to revalidate, but I assume that on
> certificate expiration it will revalidate when you ask for a renew (certs
> are valid for 90 days, they recommend renew at 60 days).
> > >
> > > The simplest is the HTTP method and is what I used for testing.  But...
> > >       • AstLinux is a router.  If port 80 is NAT forwarded then it
> won't work.
> > >       • If you don't have port 80 open (firewall blocked) then it
> won't work.
> > >       • They don't publish their IP addresses so you cannot add
> firewall rule just for them (and they state that their IPs may change or
> they may use multiple servers at their end so don't rely on that).
> > >       • You can have lighttpd special handle the request from
> LetsEncrypt and redirect it.  But of course requires port 80 to be open.
> > > For one-off issuing of the certificate we could probably live with
> temporarily opening port 80 and/or adjusting firewall rules but doing this
> automatically every 60 days may become problematic.  I need to give more
> thought to this.
> > >
> > > So for AstLinux it feels like the DNS TXT record method might be
> better.  The acme.sh client (which is what I used for testing...
> https://github.com/Neilpang/acme.sh)has support for several DNS services
> and you can add support yourself for those not provided (and presumably
> contribute back).  The service I use (freedns.afraid.org) is not yet
> among the ones acme.sh support.  Nor is google domains.  So I have not
> tested this method yet.
> > >
> > > I have not looked at other clients but acme.sh seems to be a pretty
> solid one.  Their "official" client, certbot, looked more complicated than
> I wanted to deal with for testing purposes.
> > >
> > > Would love to get folks opinion on this topic and thoughts on how best
> to implement.
> > >
> > > David
> > >
> > > ------------------------------------------------------------
> ------------------
> > > Developer Access Program for Intel Xeon Phi Processors
> > > Access to Intel Xeon Phi processor-based developer platforms.
> > > With one year of Intel Parallel Studio XE.
> > > Training and support from Colfax.
> > > Order your platform today. http://sdm.link/xeonphi_______
> ________________________________________
> > > Astlinux-devel mailing list
> > > Ast...@li...
> > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > >
> > > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
> >
> >
> > ------------------------------------------------------------
> ------------------
> > Developer Access Program for Intel Xeon Phi Processors
> > Access to Intel Xeon Phi processor-based developer platforms.
> > With one year of Intel Parallel Studio XE.
> > Training and support from Colfax.
> > Order your platform today. http://sdm.link/xeonphi
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
> >
> > ------------------------------------------------------------
> ------------------
> > Developer Access Program for Intel Xeon Phi Processors
> > Access to Intel Xeon Phi processor-based developer platforms.
> > With one year of Intel Parallel Studio XE.
> > Training and support from Colfax.
> > Order your platform today. http://sdm.link/xeonphi_______
> ________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>
>
> ------------------------------------------------------------
> ------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>

Thanks David for answering my question, makes total sense that each DNS name must be independently challenged and validated.

> I'm not sure I understand your point about connecting to HTTPS on a local isolated (no public internet connection) network.

I was wrong, I now see the intermediate "Let's Encrypt Authority X3" cert is installed on the server and cross-signed with "DST Root CA X3" for root CA compatibility.

Chain of Trust
https://letsencrypt.org/certificates/

The browser's CRL / OCSP check would fail (with no internet), but I think that is out of band and not critical to the initial certificate check.


> So for AstLinux it feels like the DNS TXT record method might be better.

I'm thinking the same that using a DNS Challenge is the best method for AstLinux.


Lonnie


On Jan 9, 2017, at 9:58 PM, David Kerr <Da...@Ke...> wrote:

> Thanks Lonnie....
> 
> LetsEcrypt can issue a single certificate for multiple domain names, so you can request for www.example.tld, sip.example.tld and xmpp.example.tld all in the one request and it will issue a single certificate valid for all.  However, LetsEncrypt is going to validate that you own each of these domain names by sending a request to each.  So 1.2.3.4 will get one validation request and 4.3.2.1 will get two separate validation requests.  Each must respond to either the HTTP or DNS validation methods.  You could redirect the HTTP requests to 4.3.2.1 on to 1.2.3.4 and have it do the work to verify, but that still requires that 4.3.2.1 has port 80 open to redirect it. I personally don't think it is a good idea to have one certificate for two separate public IP servers, fine for multiple services (say sip and xmpp) at the same IP.
> 
> I'm not sure I understand your point about connecting to HTTPS on a local isolated (no public internet connection) network.  Browsers should still be able to connect as the root certificate for LetsEncrypt (ISRG Root X1) is embedded into most recent browsers so I don't think it needs to go out to public internet to validate the certs?
> 
> David
> 
> 
> 
> On Mon, Jan 9, 2017 at 4:35 PM, Lonnie Abelbeck <li...@lo...> wrote:
> David, Excellent synopsis.
> 
> As for what is useful with AstLinux, I think SIP-TLS and XMPP are good candidates for LetsEncrypt certs, but in general not much else IMHO.
> 
> For the HTTPS case, I have found storing self signed cert exceptions in browsers simple, and unless major changes in browsers occur, they display as a trusted site.
> 
> In an appliance like AstLinux, managing via HTTPS is occasionally done locally without an active internet connection, using publicly signed certs would be a problem in that case.  Additionally a split-horison DNS can be setup in AstLinux which could be an issue matching the cert's "Subject Alternative Name" DNS Name's.
> 
> In our case for OpenVPN and IPsec, passing out the self-signed CA is not a big deal for a few VPN clients.  If you were running a campus of VPN clients that would be different.
> 
> 
> A question.  Say you want a LetsEncrypt cert for www.example.tld (A record 1.2.3.4, public HTTP server) , sip.example.tld and xmpp.example.tld (both, A record 4.3.2.1, AstLinux public IP).  Could a LetsEncrypt cert be generated for all three DNS Names only using a HTTP server at 1.2.3.4 ?  If so, the LetsEncrypt cert could be generated and renewed remotely and AstLinux could keep it's copies in sync with the remote server.
> 
> Lonnie
> 
> 
> 
> On Jan 9, 2017, at 11:40 AM, David Kerr <Da...@Ke...> wrote:
> 
> > Devs,
> >   One of the things that has been bugging me for a while is that AstLinux HTTPS self signed certificates are not trusted by browsers.  I would really like to have AstLinux use trusted certificates but until recently that has meant paying real $$$'s to a CA.
> >
> > A couple of years ago a non-profit org was set up, LetsEncrypt.org, to remove this barrier and encourage everyone to use HTTPS for their web servers.  It has now matured to a point where it might make sense to adopt it in AstLinux.
> >
> > I have been investigating how easy it would be to have AstLinux use trusted certificates from LetsEncrypt.  Here is an initial analysis...
> >
> > Before LetsEncrypt will issue you a certificate it has to validate that you are who you say you are.  So if you ask for a certificate for example.com then it needs to ensure that your really are example.com.  There are a couple of options for this.  First it does a DNS lookup on example.com and then either...
> >
> >       • Uses HTTP to example.com with challenge/response that validates that you own the webserver at example.com.  It will ONLY do this over port 80 (or 443, but that is catch 22).  There are many requests online that they support another port but ostensibly for security reasons they refuse to do that.  Pressure is building on them, but so far no change.
> >       • Uses a TXT record at your DNS registrar... it asks the client (certbot/acme/dehydrated/whatever) to add a TXT record to the example.com DNS server entries then it validates that the TXT entry is indeed there.  Then client is asked to delete the TXT record.
> > It does not perform validation every time you request a certificate... if you are already validated then it can skip that part of the process.  I do not know how often it needs to revalidate, but I assume that on certificate expiration it will revalidate when you ask for a renew (certs are valid for 90 days, they recommend renew at 60 days).
> >
> > The simplest is the HTTP method and is what I used for testing.  But...
> >       • AstLinux is a router.  If port 80 is NAT forwarded then it won't work.
> >       • If you don't have port 80 open (firewall blocked) then it won't work.
> >       • They don't publish their IP addresses so you cannot add firewall rule just for them (and they state that their IPs may change or they may use multiple servers at their end so don't rely on that).
> >       • You can have lighttpd special handle the request from LetsEncrypt and redirect it.  But of course requires port 80 to be open.
> > For one-off issuing of the certificate we could probably live with temporarily opening port 80 and/or adjusting firewall rules but doing this automatically every 60 days may become problematic.  I need to give more thought to this.
> >
> > So for AstLinux it feels like the DNS TXT record method might be better.  The acme.sh client (which is what I used for testing... https://github.com/Neilpang/acme.sh)has support for several DNS services and you can add support yourself for those not provided (and presumably contribute back).  The service I use (freedns.afraid.org) is not yet among the ones acme.sh support.  Nor is google domains.  So I have not tested this method yet.
> >
> > I have not looked at other clients but acme.sh seems to be a pretty solid one.  Their "official" client, certbot, looked more complicated than I wanted to deal with for testing purposes.
> >
> > Would love to get folks opinion on this topic and thoughts on how best to implement.
> >
> > David
> >
> > ------------------------------------------------------------------------------
> > Developer Access Program for Intel Xeon Phi Processors
> > Access to Intel Xeon Phi processor-based developer platforms.
> > With one year of Intel Parallel Studio XE.
> > Training and support from Colfax.
> > Order your platform today. http://sdm.link/xeonphi_______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi_______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Thanks Lonnie....

LetsEcrypt can issue a single certificate for multiple domain names, so you
can request for www.example.tld, sip.example.tld and xmpp.example.tld all
in the one request and it will issue a single certificate valid for all.
However, LetsEncrypt is going to validate that you own each of these domain
names by sending a request to each.  So 1.2.3.4 will get one validation
request and 4.3.2.1 will get two separate validation requests.  Each must
respond to either the HTTP or DNS validation methods.  You could redirect
the HTTP requests to 4.3.2.1 on to 1.2.3.4 and have it do the work to
verify, but that still requires that 4.3.2.1 has port 80 open to redirect
it. I personally don't think it is a good idea to have one certificate for
two separate public IP servers, fine for multiple services (say sip and
xmpp) at the same IP.

I'm not sure I understand your point about connecting to HTTPS on a local
isolated (no public internet connection) network.  Browsers should still be
able to connect as the root certificate for LetsEncrypt (ISRG Root X1) is
embedded into most recent browsers so I don't think it needs to go out to
public internet to validate the certs?

David



On Mon, Jan 9, 2017 at 4:35 PM, Lonnie Abelbeck <li...@lo...>
wrote:

> David, Excellent synopsis.
>
> As for what is useful with AstLinux, I think SIP-TLS and XMPP are good
> candidates for LetsEncrypt certs, but in general not much else IMHO.
>
> For the HTTPS case, I have found storing self signed cert exceptions in
> browsers simple, and unless major changes in browsers occur, they display
> as a trusted site.
>
> In an appliance like AstLinux, managing via HTTPS is occasionally done
> locally without an active internet connection, using publicly signed certs
> would be a problem in that case.  Additionally a split-horison DNS can be
> setup in AstLinux which could be an issue matching the cert's "Subject
> Alternative Name" DNS Name's.
>
> In our case for OpenVPN and IPsec, passing out the self-signed CA is not a
> big deal for a few VPN clients.  If you were running a campus of VPN
> clients that would be different.
>
>
> A question.  Say you want a LetsEncrypt cert for www.example.tld (A record
> 1.2.3.4, public HTTP server) , sip.example.tld and xmpp.example.tld (both,
> A record 4.3.2.1, AstLinux public IP).  Could a LetsEncrypt cert be
> generated for all three DNS Names only using a HTTP server at 1.2.3.4 ?  If
> so, the LetsEncrypt cert could be generated and renewed remotely and
> AstLinux could keep it's copies in sync with the remote server.
>
> Lonnie
>
>
>
> On Jan 9, 2017, at 11:40 AM, David Kerr <Da...@Ke...> wrote:
>
> > Devs,
> >   One of the things that has been bugging me for a while is that
> AstLinux HTTPS self signed certificates are not trusted by browsers.  I
> would really like to have AstLinux use trusted certificates but until
> recently that has meant paying real $$$'s to a CA.
> >
> > A couple of years ago a non-profit org was set up, LetsEncrypt.org, to
> remove this barrier and encourage everyone to use HTTPS for their web
> servers.  It has now matured to a point where it might make sense to adopt
> it in AstLinux.
> >
> > I have been investigating how easy it would be to have AstLinux use
> trusted certificates from LetsEncrypt.  Here is an initial analysis...
> >
> > Before LetsEncrypt will issue you a certificate it has to validate that
> you are who you say you are.  So if you ask for a certificate for
> example.com then it needs to ensure that your really are example.com.
> There are a couple of options for this.  First it does a DNS lookup on
> example.com and then either...
> >
> >       • Uses HTTP to example.com with challenge/response that validates
> that you own the webserver at example.com.  It will ONLY do this over
> port 80 (or 443, but that is catch 22).  There are many requests online
> that they support another port but ostensibly for security reasons they
> refuse to do that.  Pressure is building on them, but so far no change.
> >       • Uses a TXT record at your DNS registrar... it asks the client
> (certbot/acme/dehydrated/whatever) to add a TXT record to the example.com
> DNS server entries then it validates that the TXT entry is indeed there.
> Then client is asked to delete the TXT record.
> > It does not perform validation every time you request a certificate...
> if you are already validated then it can skip that part of the process.  I
> do not know how often it needs to revalidate, but I assume that on
> certificate expiration it will revalidate when you ask for a renew (certs
> are valid for 90 days, they recommend renew at 60 days).
> >
> > The simplest is the HTTP method and is what I used for testing.  But...
> >       • AstLinux is a router.  If port 80 is NAT forwarded then it won't
> work.
> >       • If you don't have port 80 open (firewall blocked) then it won't
> work.
> >       • They don't publish their IP addresses so you cannot add firewall
> rule just for them (and they state that their IPs may change or they may
> use multiple servers at their end so don't rely on that).
> >       • You can have lighttpd special handle the request from
> LetsEncrypt and redirect it.  But of course requires port 80 to be open.
> > For one-off issuing of the certificate we could probably live with
> temporarily opening port 80 and/or adjusting firewall rules but doing this
> automatically every 60 days may become problematic.  I need to give more
> thought to this.
> >
> > So for AstLinux it feels like the DNS TXT record method might be
> better.  The acme.sh client (which is what I used for testing...
> https://github.com/Neilpang/acme.sh)has support for several DNS services
> and you can add support yourself for those not provided (and presumably
> contribute back).  The service I use (freedns.afraid.org) is not yet
> among the ones acme.sh support.  Nor is google domains.  So I have not
> tested this method yet.
> >
> > I have not looked at other clients but acme.sh seems to be a pretty
> solid one.  Their "official" client, certbot, looked more complicated than
> I wanted to deal with for testing purposes.
> >
> > Would love to get folks opinion on this topic and thoughts on how best
> to implement.
> >
> > David
> >
> > ------------------------------------------------------------
> ------------------
> > Developer Access Program for Intel Xeon Phi Processors
> > Access to Intel Xeon Phi processor-based developer platforms.
> > With one year of Intel Parallel Studio XE.
> > Training and support from Colfax.
> > Order your platform today. http://sdm.link/xeonphi_______
> ________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>
>
> ------------------------------------------------------------
> ------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>

David, Excellent synopsis.

As for what is useful with AstLinux, I think SIP-TLS and XMPP are good candidates for LetsEncrypt certs, but in general not much else IMHO.

For the HTTPS case, I have found storing self signed cert exceptions in browsers simple, and unless major changes in browsers occur, they display as a trusted site.

In an appliance like AstLinux, managing via HTTPS is occasionally done locally without an active internet connection, using publicly signed certs would be a problem in that case.  Additionally a split-horison DNS can be setup in AstLinux which could be an issue matching the cert's "Subject Alternative Name" DNS Name's.

In our case for OpenVPN and IPsec, passing out the self-signed CA is not a big deal for a few VPN clients.  If you were running a campus of VPN clients that would be different.


A question.  Say you want a LetsEncrypt cert for www.example.tld (A record 1.2.3.4, public HTTP server) , sip.example.tld and xmpp.example.tld (both, A record 4.3.2.1, AstLinux public IP).  Could a LetsEncrypt cert be generated for all three DNS Names only using a HTTP server at 1.2.3.4 ?  If so, the LetsEncrypt cert could be generated and renewed remotely and AstLinux could keep it's copies in sync with the remote server.

Lonnie



On Jan 9, 2017, at 11:40 AM, David Kerr <Da...@Ke...> wrote:

> Devs,
>   One of the things that has been bugging me for a while is that AstLinux HTTPS self signed certificates are not trusted by browsers.  I would really like to have AstLinux use trusted certificates but until recently that has meant paying real $$$'s to a CA.
> 
> A couple of years ago a non-profit org was set up, LetsEncrypt.org, to remove this barrier and encourage everyone to use HTTPS for their web servers.  It has now matured to a point where it might make sense to adopt it in AstLinux.
> 
> I have been investigating how easy it would be to have AstLinux use trusted certificates from LetsEncrypt.  Here is an initial analysis...
> 
> Before LetsEncrypt will issue you a certificate it has to validate that you are who you say you are.  So if you ask for a certificate for example.com then it needs to ensure that your really are example.com.  There are a couple of options for this.  First it does a DNS lookup on example.com and then either...
> 
> 	• Uses HTTP to example.com with challenge/response that validates that you own the webserver at example.com.  It will ONLY do this over port 80 (or 443, but that is catch 22).  There are many requests online that they support another port but ostensibly for security reasons they refuse to do that.  Pressure is building on them, but so far no change.
> 	• Uses a TXT record at your DNS registrar... it asks the client (certbot/acme/dehydrated/whatever) to add a TXT record to the example.com DNS server entries then it validates that the TXT entry is indeed there.  Then client is asked to delete the TXT record.
> It does not perform validation every time you request a certificate... if you are already validated then it can skip that part of the process.  I do not know how often it needs to revalidate, but I assume that on certificate expiration it will revalidate when you ask for a renew (certs are valid for 90 days, they recommend renew at 60 days).
> 
> The simplest is the HTTP method and is what I used for testing.  But...
> 	• AstLinux is a router.  If port 80 is NAT forwarded then it won't work.
> 	• If you don't have port 80 open (firewall blocked) then it won't work. 
> 	• They don't publish their IP addresses so you cannot add firewall rule just for them (and they state that their IPs may change or they may use multiple servers at their end so don't rely on that).
> 	• You can have lighttpd special handle the request from LetsEncrypt and redirect it.  But of course requires port 80 to be open.
> For one-off issuing of the certificate we could probably live with temporarily opening port 80 and/or adjusting firewall rules but doing this automatically every 60 days may become problematic.  I need to give more thought to this.
> 
> So for AstLinux it feels like the DNS TXT record method might be better.  The acme.sh client (which is what I used for testing... https://github.com/Neilpang/acme.sh)has support for several DNS services and you can add support yourself for those not provided (and presumably contribute back).  The service I use (freedns.afraid.org) is not yet among the ones acme.sh support.  Nor is google domains.  So I have not tested this method yet.
> 
> I have not looked at other clients but acme.sh seems to be a pretty solid one.  Their "official" client, certbot, looked more complicated than I wanted to deal with for testing purposes.
> 
> Would love to get folks opinion on this topic and thoughts on how best to implement.
> 
> David
> 
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi_______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Devs,
  One of the things that has been bugging me for a while is that AstLinux
HTTPS self signed certificates are not trusted by browsers.  I would really
like to have AstLinux use trusted certificates but until recently that has
meant paying real $$$'s to a CA.

A couple of years ago a non-profit org was set up, LetsEncrypt.org, to
remove this barrier and encourage everyone to use HTTPS for their web
servers.  It has now matured to a point where it might make sense to adopt
it in AstLinux.

I have been investigating how easy it would be to have AstLinux use trusted
certificates from LetsEncrypt.  Here is an initial analysis...

Before LetsEncrypt will issue you a certificate it has to validate that you
are who you say you are.  So if you ask for a certificate for example.com then
it needs to ensure that your really are example.com.  There are a couple of
options for this.  First it does a DNS lookup on example.com and then
either...


   1. Uses HTTP to example.com with challenge/response that validates that
   you own the webserver at example.com.  It will ONLY do this over port 80
   (or 443, but that is catch 22).  There are many requests online that they
   support another port but ostensibly for security reasons they refuse to do
   that.  Pressure is building on them, but so far no change.
   2. Uses a TXT record at your DNS registrar... it asks the client
   (certbot/acme/dehydrated/whatever) to add a TXT record to the
example.com DNS
   server entries then it validates that the TXT entry is indeed there.  Then
   client is asked to delete the TXT record.

It does not perform validation every time you request a certificate... if
you are already validated then it can skip that part of the process.  I do
not know how often it needs to revalidate, but I assume that on certificate
expiration it will revalidate when you ask for a renew (certs are valid for
90 days, they recommend renew at 60 days).

The simplest is the HTTP method and is what I used for testing.  But...

   - AstLinux is a router.  If port 80 is NAT forwarded then it won't work.
   - If you don't have port 80 open (firewall blocked) then it won't work.
   - They don't publish their IP addresses so you cannot add firewall rule
   just for them (and they state that their IPs may change or they may use
   multiple servers at their end so don't rely on that).
   - You can have lighttpd special handle the request from LetsEncrypt and
   redirect it.  But of course requires port 80 to be open.

For one-off issuing of the certificate we could probably live with
temporarily opening port 80 and/or adjusting firewall rules but doing this
automatically every 60 days may become problematic.  I need to give more
thought to this.

So for AstLinux it feels like the DNS TXT record method might be better.
The acme.sh client (which is what I used for testing...
https://github.com/Neilpang/acme.sh)has support for several DNS services
and you can add support yourself for those not provided (and presumably
contribute back).  The service I use (freedns.afraid.org) is not yet among
the ones acme.sh support.  Nor is google domains.  So I have not tested
this method yet.

I have not looked at other clients but acme.sh seems to be a pretty solid
one.  Their "official" client, certbot, looked more complicated than I
wanted to deal with for testing purposes.

Would love to get folks opinion on this topic and thoughts on how best to
implement.

David

> As of Revision 8005 in the SVN, the 'ntp' package has been totally replaced by the new 'chrony' package, running with 'ntp' user/group privileges.
> 
> The service name is still "ntpd" as before, since chrony is still an ntp daemon.

BTW, chrony handles leap seconds, here is the default action in action:
--
Dec 31 17:59:59 time user.notice kernel: Clock: inserting leap second 23:59:60 UTC
Dec 31 18:00:01 time daemon.info chronyd[824]: System clock status reset after leap second
--

Happy leap second and New Year !

Lonnie