EFF's Let's Encrypt is about to start mid of November. It allows getting SSL-certificates quick, easy and without cost. This is an important step for offering more SSL/TLS-based websites. Read more at https://letsencrypt.org/ Please provide packages for the client. Even if Let's Encrypt is not yet released to public, Mageia should be prepared and offer packages timely. * Source: https://github.com/letsencrypt/letsencrypt * Thoughts on RPM builds: https://github.com/letsencrypt/letsencrypt/issues/15 looks lik there are Fedora packages already. * Debian Packaging work can be found at can be https://github.com/letsencrypt/letsencrypt-debian About the tool: - It seams to be pure Python, thus should be easy to install and package. The Let's Encrypt Client is a tool to automatically receive and install X.509 certificates to enable TLS on servers. The client will interoperate with the Let's Encrypt CA which will be issuing browser-trusted certificates for free. It's all automated: * The tool will prove domain control to the CA and submit a CSR (Certificate Signing Request). * If domain control has been proven, a certificate will get issued and the tool will automatically install it.
CC: (none) => alejandro.anv
Assignee: bugsquad => pkg-bugsSource RPM: Please prepare RPMs for => (none)
CC: (none) => luke.nukem.jones
Since I wanted to try letsencrypt and don't know how to package it, I simply added a bootstrap for mageia. Works for me, YMMV https://github.com/letsencrypt/letsencrypt/pull/1742
CC: (none) => luca
So letsencrypt works for the Mageia type of apache configuration in addition to the debian type configuration. The beta of letsencrypt is out.
CC: (none) => bjarne.thomsen
I don't know: I'm using lighttpd so I only tested the webroot plugin (as well as the standalone one).
CC'ing sysadmin team, in case they intend on using letsencrypt. However, also setting Version to "Cauldron" and Severity to "Enhancement", because that's what we always do with package requests. https://wiki.mageia.org/en/How_to_report_a_bug_properly#How_to_file_a_package_request
CC: (none) => marja11, sysadmin-bugsVersion: 5 => CauldronSource RPM: (none) => letsencryptSeverity: major => enhancement
to help, here the Fedora package http://pkgs.fedoraproject.org/cgit/letsencrypt.git/
CC: (none) => makowski.mageia
(In reply to Philippe Makowski from comment #5) > to help, here the Fedora package > http://pkgs.fedoraproject.org/cgit/letsencrypt.git/ thx :-)
Summary: Please package EFF's letsencrypt client tool soon => letsencrypt, client tool for Letâs Encrypt, a free, automated and open Certificate Authority
By the way, the official client is perhaps not the best. see : https://www.metachris.com/2015/12/comparison-of-10-acme-lets-encrypt-clients/ acme-tiny (https://github.com/diafygi/acme-tiny) seems a good one
(In reply to Philippe Makowski from comment #7) > By the way, the official client is perhaps not the best. > see : > https://www.metachris.com/2015/12/comparison-of-10-acme-lets-encrypt-clients/ > > acme-tiny (https://github.com/diafygi/acme-tiny) seems a good one I was checking this... the official client is completely automatic. You only need to provide the document-root for http server, your e-mail address and the domain or domains you are using and it doues all by itself. Only one command... and the only you need to do es to add a line to cron for auto-refresh the cert. With acme-tiny you need to do all manually (about 6 or 7 commands).
CC: (none) => mageia
Has there been any update on this? I need to renew my cert on May 1st and it made me think about Let's Encrypt. I now the package won't be ready and backported by May 1st, but I thought I would see if the package would be in Mageia 6.
CC: (none) => jeffrobinsSAE
(In reply to Jeff Robins from comment #9) > Has there been any update on this? > nope for what I know. but really, you don't need Let's Encrypt Official Client to use Let's Encrypt certificates. I personnaly use with success https://github.com/neurobin/letsacme and https://github.com/Neilpang/le the last one is very cool as it is only a bash file.
Let's Encrypt Official Client failed when it couldn't find yum of dnf. letsacme seemed overly complicated, especially when compared to the official client. It looked like I needed to alter a json file. https://github.com/Neilpang/le was actually changed to https://github.com/Neilpang/acme.sh. https://github.com/Neilpang/acme.sh worked perfectly and was very simple to use. The command line arguments were either exactly or very similar to those of the official client. My only problem is that no-ip.com sub-domains are still waiting for inclusion into the Public Suffix List, so the ACME protocol refuses to sign the cert. This is not a problem with the software or the protocol.
And the official client is now https://github.com/certbot/certbot But still I prefer to use https://github.com/Neilpang/acme.sh
(In reply to Philippe Makowski from comment #12) > And the official client is now https://github.com/certbot/certbot > > But still I prefer to use https://github.com/Neilpang/acme.sh We do have python-acme and python3-acme in our repositories, they're from the certbot project: https://pypi.python.org/pypi/acme Is that enough to mark this bug report as fixed? @ Philippe Do you still want Neil Pang's alternative to be packaged? (We should clone this bug report,then)
IMO this is fixed since there are valid alternatives available. As I'm the original reporter, I'm closing this as "FIXED".
Status: NEW => RESOLVEDResolution: (none) => FIXED