\n\tThe Let\u2019s Encrypt client requires Python 2.7, which is not installed on CentOS 6.x by default. Simply upgrading Python will break several system utilities, like yum, so we\u2019ll start by installing Python 2.7 in an alternate location. If you\u2019re using a distro that includes Python 2.7, or you already have it installed, you can skip the next several steps.\n<\/p>\n
\n\tFirst, using yum, install the development tools and libraries we\u2019ll need to build Python from source.\n<\/p>\n
\n\tyum groupinstall \"Development tools\"
\nyum install zlib-devel bzip2-devel openssl-devel ncurses-devel sqlite-devel readline-devel tk-devel gdbm-devel db4-devel libpcap-devel xz-devel\n<\/p>\n
\n\tDownload the latest version of the Python 2.7 branch (2.7.11 as of this writing, but checkhttp:\/\/python.org\/downloads\/<\/a> and update the version numbers as appropriate.\n<\/p>\n \n\twget http:\/\/python.org\/ftp\/python\/2.7.11\/Python-2.7.11.tar.xz\n<\/p>\n \n\tUnzip the Python tarball and change into the newly create source directory.\n<\/p>\n \n\ttar xf Python-2.7.11.tar.xz Run the configure script.\n<\/p>\n \n\t.\/configure --prefix=\/usr\/local --enable-shared LDFLAGS=\"-Wl,-rpath \/usr\/local\/lib\"\n<\/p>\n \n\tBuild and install the new Python binary. We\u2019re using \u201cmake altinstall\u201d to ensure that we don\u2019t interfere the system version of Python (this will name the binary python2.7 instead of just python).\n<\/p>\n \n\tmake \n\tThanks to Daniel Eriksson and Too Much Data<\/a> for the How to install Python 2.7 and Python 3.3 on CentOS 6<\/a> post, from which my instructions are based. I highly recommend reading that post, as my instructions are only the bare minimum needed to get Let\u2019s Encrypt working.<\/em>\n<\/p>\n \n\tInstalling Let\u2019s Encrypt<\/strong>\n<\/p>\n \n\tNow that we have the right Python version, we can install the Let\u2019s Encrypt ACME client. We\u2019ll also install my installation tool (which isn\u2019t much more than a bash script).\n<\/p>\n \n\t\/usr\/local is intended for locally installed software (as opposed to system provided software), so it seems like a good place to put these tools.\n<\/p>\n \n\tcd \/usr\/local<\/p>\n Clone the official Let\u2019s Encrypt ACME client and my installation tool from GitHub.\n<\/p>\n \n\tgit clone https:\/\/github.com\/letsencrypt\/letsencrypt \n\tLet\u2019s Encrypt\u2019s ACME protocol validates that a requestor is in control of the domain by checking for a the availability of a randomly named file over the web. It can do this with its own web server, or it can write a file to the web root of an existing server running on the domain. Since a Vesta server has many different web roots, we\u2019ll tell let\u2019s Encrypt to write these files to a central location and then configure Apache to look there for incoming validation requests.\n<\/p>\n \n\tFirst, create the Let\u2019s Encrypt webroot directory.\n<\/p>\n \n\tmkdir -p \/etc\/letsencrypt\/webroot\n<\/p>\n \n\tThen create a symlink to the letsencrypt.conf file in my GitHub repository.\n<\/p>\n \n\tln -s \/usr\/local\/letsencrypt-vesta\/letsencrypt.conf \/etc\/httpd\/conf.d\/letsencrypt.conf\n<\/p>\n \n\tFinally, restart Apache so it will pick up the configuration change.\n<\/p>\n \n\tservice httpd restart\n<\/p>\n \n\tEverything is installed and ready to go, but to run the tools you\u2019ll need to specify the full path to them, since they aren\u2019t in your PATH environment variable. A quick fix for this is to symlink them inside \/usr\/local\/bin.\n<\/p>\n \n\tln -s \/usr\/local\/letsencrypt\/letsencrypt-auto \/usr\/local\/bin\/letsencrypt-auto \n\tNow you\u2019re ready to create your first certificate.\n<\/p>\n \n\tlets encrypt-vesta USERNAME DOMAIN\n<\/p>\n \n\tSubstitute a valid Vesta user account for USERNAME and a domain hosted on that account for DOMAIN. The script will look up the account and pull the email address listed with it, using that as the contact email used in the certificate request. It will also look up the list of domain aliases associated with the domain and will include all of them as subject alternate names (SANs) in the certificate request. SANs function as additional domains on the certificate\u2014each one will be recognized as a trusted domain by users\u2019 browsers.\n<\/p>\n \n\tThe first time you run the script, the Let\u2019s Encrypt client will do some setup work, so it may take a minute or two. Future runs won\u2019t require this additional work and should complete faster.\n<\/p>\n \n\tThe certificates issued by Let\u2019s Encrypt are valid for 90 days. It is recommended that you renew them every 60 days to allow ample time to mitigate issues such as reissue errors and service interruptions that might occur and leave you with an expired cert.\n<\/p>\n \n\tLet\u2019s Encrypt is currently in beta and, while they offer unlimited certificates, they do have some limitations in place, at least for now. As of this writing, they currently only allow ten certificate requests from a single IP address over a three hour period and limit the number of SANs on a single certificate to 100. There are also limits on the number of unverified requests (as in a certificate is requested, but the validation process fails) allowed, though this shouldn\u2019t be ann issue for most admins. These numbers may change over time as the technology platform matures and demand for the service adjusts.<\/p>\n","protected":false},"excerpt":{"rendered":"
\ncd Python-2.7.11<\/p>\n
\nmake altinstall\n<\/p>\n
\ngit clone https:\/\/github.com\/interbrite\/letsencrypt-vesta\n<\/p>\n
\nln -s \/usr\/local\/letsencrypt-vesta\/letsencrypt-vesta \/usr\/local\/bin\/letsencrypt-vesta\n<\/p>\n