[How-To] Installing SSL from Let's Encrypt

cPMatthewV

December 04, 2015 23:37

UPDATE: As of cPanel and WHM version 58 the AutoSSL feature now includes Let's Encrypt support. This blog post will help you get set up there. Anyone using the custom workaround on this thread may want to keep this in mind when using these steps. The following below will show you how to install the Let's Encrypt client and how to generate and install SSL certificates from Lets Encrypt via the WHM API using a custom workaround. Installing the Let's Encrypt Client on CentOS 6.x Please note: The Let's Encrypt client requires / prefers python 2.7, so we will install Python 2.7 alongside Python 2.6. Don't worry it won't break anything.


rpm -ivh https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
rpm -ivh https://rhel6.iuscommunity.org/ius-release.rpm
yum -y install git python27 python27-devel python27-pip python27-setuptools python27-virtualenv --enablerepo=ius
cd /root
git clone https://github.com/letsencrypt/letsencrypt
cd /root/letsencrypt
sed -i "s|--python python2|--python python2.7|" letsencrypt-auto
./letsencrypt-auto --verbose

Installing the Let's Encrypt Client on CentOS 7.x


yum -y install git
cd /root
git clone https://github.com/letsencrypt/letsencrypt
cd /root/letsencrypt
./letsencrypt-auto --verbose

NOTE: The Let's Encrypt installer will create the /etc/letsencrypt/renewal and /etc/letsencrypt/csr directories as world readable. The administrator may want to tighten the readability of these directories to fit their requirements. Generate an SSL You will be required to enter your email and accept their license agreement. I would recommend using the server admins email. Also make sure you replace "cPanelUser" with your actual username. This is require to allow the Let's Encrypt client to create the auth files for the domain and be able to access them during the authorization. Please note if you are installing a subdomain or addon domain that points to another path, that you set the path of the subdomain or addon domain.


cd /root/letsencrypt
./letsencrypt-auto --text --agree-tos --email email@domain.com certonly --renew-by-default --webroot --webroot-path /home/cPanelUser/public_html/ -d domain.com -d www.domain.com

For all subsequent runs use the following below, as there is no need to re-provide your email or re-agree to the TOS.


cd /root/.local/share/letsencrypt/bin/
./letsencrypt --text certonly --renew-by-default --webroot --webroot-path /home/cPanelUser/public_html/ -d domain.com -d www.domain.com

By adding the renew-by-default command you can add this to a cron to run every 60 (recommended) or say 85 days to avoid this expiring before you are sure the new certs are retrieved. Then all you need to do is simply run the install script below again to install the updated certificate to cPanel.


0 0 */60 * * /root/.local/share/letsencrypt/bin/letsencrypt --text certonly --renew-by-default --webroot --webroot-path /home/cPanelUser/public_html/ -d domain.com -d www.domain.com; /root/installssl.pl domain.com

You can also generate an SSL certificate via Get HTTPS for free!, there are additional steps that are required however. Script to automatically install the SSLs you generated This script will be used to install the SSL's you generated to cPanel/WHM via the API. Please note the following things. 1. You must replace "rootpass" with your actual root password. 2. The CA Bundle is not by default in the location below and is generally saved to /etc/letsencrypt/live/domain.com/fullchain.pm and is the second cert in the file. I have included the CA Bundle below the script so you can create this.


#!/usr/local/cpanel/3rdparty/bin/perl

use strict;
use LWP::UserAgent;
use LWP::Protocol::https;
use MIME::Base64;
use IO::Socket::SSL;
use URI::Escape;

my $user = "root";
my $pass = "rootpass";

my $auth = "Basic " . MIME::Base64::encode( $user . ":" . $pass );

my $ua = LWP::UserAgent->new(
    ssl_opts   => { verify_hostname => 0, SSL_verify_mode => 'SSL_VERIFY_NONE', SSL_use_cert => 0 },
);

my $dom = $ARGV[0];

my $certfile = "/etc/letsencrypt/live/$dom/cert.pem";
my $keyfile = "/etc/letsencrypt/live/$dom/privkey.pem";
my $cafile =  "/etc/letsencrypt/live/$dom/chain.pem";

my $certdata;
my $keydata;
my $cadata;

open(my $certfh, '<', $certfile) or die "cannot open file $certfile";
    {
        local $/;
        $certdata = <$certfh>;
    }
    close($certfh);

open(my $keyfh, '<', $keyfile) or die "cannot open file $keyfile";
    {
        local $/;
        $keydata = <$keyfh>;
    }
    close($keyfh);

open(my $cafh, '<', $cafile) or die "cannot open file $cafile";
    {
        local $/;
        $cadata = <$cafh>;
    }
    close($cafh);

my $cert = uri_escape($certdata);
my $key = uri_escape($keydata);
my $ca = uri_escape($cadata);

my $request = HTTP::Request->new( POST => "https://127.0.0.1:2087/json-api/installssl?api.version=1&domain=$dom&crt=$cert&key=$key&cab=$ca" );
$request->header( Authorization => $auth );
my $response = $ua->request($request);
print $response->content;

Add the Let's Encrypt CA Bundle Let's Encrypt should now include the CA Bundle when generating certs. It will be saved as chain.pem In the event that is missing or not created you can manually create the CA for use with the script below and change "my $cafile" in the script above to use this file instead.


vi /etc/letsencrypt/live/bundle.txt

When editing that file set the following below and save Note: This has been updated with the Let's Encrypt Authority X3

Running the script First make the script executable. Then run the script with the main domain of the certificate generated from Let's Encrypt.


chmod +x installssl.pl
./installssl.pl domain.com

There you go you are all set and ready to generate and install SSLs from Let's Encrypt automatically via the command line.

Comments

118 comments

Spork Schivago

February 02, 2016 01:56
I've been banging my head against the wall trying to get this to install properly. I have a new Centos7 droplet on Digital Ocean. I've installed Cpanel/WHM with no problem, however, when I attempt to install LetsEncrypt, I receiving the following error:
root@drink [~/letsencrypt]# sudo ./letsencrypt-auto --verbose Updating letsencrypt and virtual environment dependencies... Requirement already up-to-date: setuptools in /root/.local/share/letsencrypt/lib/python2.7/site-packages Requirement already up-to-date: pip in /root/.local/share/letsencrypt/lib/python2.7/site-packages Requirement already up-to-date: letsencrypt in /root/.local/share/letsencrypt/lib/python2.7/site-packages Requirement already up-to-date: letsencrypt-apache in /root/.local/share/letsencrypt/lib/python2.7/site-packages Requirement already up-to-date: zope.interface in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt) Requirement already up-to-date: setuptools in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt) Requirement already up-to-date: python2-pythondialog>=3.2.2rc1 in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt) Requirement already up-to-date: PyOpenSSL in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt) Requirement already up-to-date: acme==0.3.0 in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt) Requirement already up-to-date: ConfigArgParse>=0.9.3 in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt) Requirement already up-to-date: parsedatetime in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt) Requirement already up-to-date: configobj in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt) Requirement already up-to-date: pytz in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt) Requirement already up-to-date: psutil>=2.1.0 in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt) Requirement already up-to-date: six in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt) Requirement already up-to-date: cryptography>=0.7 in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt) Requirement already up-to-date: zope.component in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt) Requirement already up-to-date: mock in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt) Requirement already up-to-date: pyrfc3339 in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt) Requirement already up-to-date: python-augeas in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from letsencrypt-apache) Requirement already up-to-date: requests in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from acme==0.3.0->letsencrypt) Requirement already up-to-date: pyasn1 in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from acme==0.3.0->letsencrypt) Requirement already up-to-date: ndg-httpsclient in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from acme==0.3.0->letsencrypt) Requirement already up-to-date: werkzeug in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from acme==0.3.0->letsencrypt) Requirement already up-to-date: idna>=2.0 in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from cryptography>=0.7->letsencrypt) Requirement already up-to-date: enum34 in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from cryptography>=0.7->letsencrypt) Requirement already up-to-date: ipaddress in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from cryptography>=0.7->letsencrypt) Requirement already up-to-date: cffi>=1.4.1 in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from cryptography>=0.7->letsencrypt) Requirement already up-to-date: zope.event in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from zope.component->letsencrypt) Requirement already up-to-date: funcsigs in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from mock->letsencrypt) Requirement already up-to-date: pbr>=0.11 in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from mock->letsencrypt) Requirement already up-to-date: pycparser in /root/.local/share/letsencrypt/lib/python2.7/site-packages (from cffi>=1.4.1->cryptography>=0.7->letsencrypt) Requesting root privileges to run with virtualenv: /root/.local/share/letsencrypt/bin/letsencrypt --verbose ???????????????????????????????????????????????????????????????????????? ? Saving debug log to /var/log/letsencrypt/letsencrypt.log ? No installers are available on your OS yet; try running "letsencrypt-auto certonly" to get a cert you can install manually
Any help would be greatly appreciated.

The message is saying there's no installer available for your OS you must generate the certificate manually and install it. You do this by running:
./letsencrypt-auto certonly -d
Replace with your domain name. Use one -d per domain name. So if you have two domain names and they're called mydomain.com and www.mydomain.com, you'd type something like:
./letsencrypt-auto certonly -d mydomain.com -d www.mydomain.com
You might also want to try using the --test-cert option until you're sure you have everything figured out and working properly.
0
Spork Schivago

February 02, 2016 01:58
- Removed - You could check to see if any certs were generated or if Let's Encrypt created the /etc/letsencrypt directory. If the /etc/letsencrypt directory exists, you could remove that. Let's Encrypt shouldn't of installed anything anywheres else besides the /root/letsencrypt directory, to my knowledge at least. Hope that helps a little.
0
EneTar

February 11, 2016 19:08
Hi I have two questions. Currently I have a multi domain certificate from COMODO on a dedicated server. 1)Does Let's encrypt issue multi domain certificates? 2)If not, how will I be able to issue a certificate for each website without the need of a dedicated IP for each website? The multidomain certificate I have right now needs only one dedicated IP Thank you
0
Spork Schivago

February 12, 2016 20:48
Hi I have two questions. Currently I have a multi domain certificate from COMODO on a dedicated server. 1)Does Let's encrypt issue multi domain certificates? 2)If not, how will I be able to issue a certificate for each website without the need of a dedicated IP for each website? The multidomain certificate I have right now needs only one dedicated IP Thank you

Hello EneTar, I know this probably isn't the answer you're looking for, but if someone here might not be able to answer your two questions, you might have better luck asking on the Let's Encrypt Community Support Forum ( Let's Encrypt Community Support ). They're pretty good with answering questions like this and they're great people. Some of the developers hang out there as well. You might want to try asking over there and seeing what they say. Best of luck to you.
0
bhargav

February 13, 2016 06:41
Hello, How can we install letsencrypt certs on Service SSL Certificates (whm/cpanel/webmail) ?
0
Spork Schivago

February 15, 2016 20:07
Hello bhargav. Have you already generated the SSL certs for the various services? You know, whm.yourdomain.com, cpanel.yourdomain.com, webmail.yourdomain.com, etc?
0
Vinayak

February 16, 2016 00:43
Anyone else getting "The client lacks sufficient authorization" ? I am trying this on CENTOS 7.2 x86_64 virtuozzo, WHM 54.0 (build 15) Domain is setup correctly and resolving fine, There is no .htaccess file in the path, I can't see any file created at /home/username/public_html/.well-known/acme-challenge/ Folders ".well-known" & "acme-challenge" are there, but no file.
0
Spork Schivago

February 16, 2016 03:45
Anyone else getting "The client lacks sufficient authorization" ? I am trying this on CENTOS 7.2 x86_64 virtuozzo, WHM 54.0 (build 15) Domain is setup correctly and resolving fine, There is no .htaccess file in the path, I can't see any file created at /home/username/public_html/.well-known/acme-challenge/ Folders ".well-known" & "acme-challenge" are there, but no file.

Could you share your let's encrypt command line that you run to generate these certs? I might have an idea as to what's going on. For whatever domains you're trying to generate certs for (ie, www.mydomain.com and mydomain.com), create a file inside the .well-known/acme-challenge directory, something like test that just has something like test inside of it, and then see if you can view that file by going to www.mydomain.com/.well-known/acme-challenge/test and mydomain.com/.well-known/acme-challenge/test Do that for every domain you're trying to create the certs for.
0
Vinayak

February 16, 2016 05:55
Commandline is
cd /root/letsencrypt ./letsencrypt-auto --text --agree-tos --email admin@mydomain.com certonly --renew-by-default --webroot --webroot-path /home/user/public_html/ -d mydomain.com -d www.mydomain.com
Already checked that URL www.mydomain.com/.well-known/acme-challenge/test and mydomain.com/.well-known/acme-challenge/test are working fine.
0
Spork Schivago

February 16, 2016 14:42
Are you running version 0.4 of Let's Encrypt?
0
Vinayak

February 16, 2016 15:31
Yes it is letsencrypt 0.4.0
0
Spork Schivago

February 16, 2016 17:32
Yes it is letsencrypt 0.4.0

This might not help, but do you think you could try posting what
ls -l /home/user/public_html/.well-known ls -l /home/user/public_html/.well-known/acme-challenge
shows? Also, did you try the .well-known/acme-challenge/test file before you ran Let's Encrypt? I'm wondering if maybe you created the .well-known / .well-known/acme-challenge directory and it has the wrong permissions so Let's Encrypt can't create the necessary files. If this is the case, perhaps something like:
chmod -R 0755 /home/user/public_html/.well-known
might fix the issue.. For my .well-known directories that Let's Encrypt created, I have:
drwxr-xr-x 3 root root 4096 Feb 15 22:09 .well-known/
However, for the acme-challenge directory, I see that the file is owned by my user (the user that owns the /home/my_real_user/ directory....and I see for the group, it's owned by nobody. Permissions are the same as the .well-known directory, just the owner and group are different. You can hide your username if you want when you post your ls command output.
0
Vinayak

February 16, 2016 17:57
Spork, thanks for your efforts and time. As you were writing, I was also testing things and found that the challenge file created is owned by root, folder .well-known is owned by root, while folder acme-challenge is owned by user. Testing the URL was working as I was creating challenge file as user and it was working, but letsencrypt webroot plugin creates the file as root (on my server owner/group for challenge file is root), hence it was not being served by Apache (mod_ruid2). I was able to get a certificate using
cd /root/letsencrypt ./letsencrypt-auto certonly --manual
Created the challenge files manually as instructed by letsencrypt process and it worked.
0
Spork Schivago

February 16, 2016 19:01
Spork, thanks for your efforts and time. As you were writing, I was also testing things and found that the challenge file created is owned by root, folder .well-known is owned by root, while folder acme-challenge is owned by user. Testing the URL was working as I was creating challenge file as user and it was working, but letsencrypt webroot plugin creates the file as root (on my server owner/group for challenge file is root), hence it was not being served by Apache (mod_ruid2). I was able to get a certificate using
cd /root/letsencrypt ./letsencrypt-auto certonly --manual
Created the challenge files manually as instructed by letsencrypt process and it worked.

I'm glad you figured it out. Maybe you'd want to let the people on the Let's Encrypt forum about the problem, why you think it was happening, how you think it should work, and what you had to do to work around the problem. Then perhaps they'll update the program so it works for people who have a similar setup? The community forum is located at: Let's Encrypt Community Support Congrats by the way!
0
Vinayak

February 16, 2016 21:24
I'm glad you figured it out. Maybe you'd want to let the people on the Let's Encrypt forum about the problem, why you think it was happening, how you think it should work, and what you had to do to work around the problem. Then perhaps they'll update the program so it works for people who have a similar setup? The community forum is located at: Let's Encrypt Community Support Congrats by the way!

Thanks for the suggestion, created this at Suggestion - flag to set challenge file owner/permission
0
Spork Schivago

February 17, 2016 02:34
Vinayak, I see they submitted your suggestion as an issue, that's great news! Hopefully it's implemented in the near future. Thanks!
0
Vinayak

February 17, 2016 02:39
Spork, thanks for supporting my suggestion there.
0
Spork Schivago

February 17, 2016 03:09
Spork, thanks for supporting my suggestion there.

I just so happened to think it was a great suggestion! I really can see how it could help a lot of people. I wish people could figure out how to keep the cPanel / WHM proxy's enabled and use Let's Encrypt without having to shutdown the web servers for the various cPanel services (webmail, webdisk, etc). The webroot plugin would work but when I create the test file and try going to something like webmail.mydomain.com/.well-known/acme-challenge/test it fails because of some missing security token or something. Only way I found around it was to disable the proxy subdomain redirects and manually create subdomain redirects myself.
0
tss

February 23, 2016 00:00
@cPMatthewV : Thanks for the scripts. Followed them, manually installing the certs via "Install an SSL Certificate on a Domain" in WHM on the individual domains, and now I have Let's Encrypt working on six domains. It did take me a few seconds to remember to go back to ~/letsencrypt to run the installssl.pl script after the first one. Only issue I had involved Drupal 7 sites; I had to completely take them offline and disable the .htaccess file to allow access to the ".well-known" directory. I also changed the ownership recursively to the site owner, and set the permissions to 755 (although I'm not entirely certain that was necessary). Oddly, there was no issue with Drupal 6 sites, although they have basically the same .htaccess file and same directory structure/permissions. Overall, installing was easy, and cPanel found the necessary files immediately. One odd glitch, though. After I installed the 1st one, I was no longer able to use the "Browse Certificates" function on the "Install an SSL Certificate on a Domain" page. The js "loading" popup appears over the grayed-out background, then it just disappears - leaving a non-functional page. Reloading the page and typing the domain name in the domain field worked to actually install the certs, and auto-discovery worked fine. Any ideas? I'm curious to see if the "Browse Certificates" functionality comes back after the next cPanel update
0
Spork Schivago

February 23, 2016 17:17
@cPMatthewV : Thanks for the scripts. Followed them, manually installing the certs via "Install an SSL Certificate on a Domain" in WHM on the individual domains, and now I have Let's Encrypt working on six domains. It did take me a few seconds to remember to go back to ~/letsencrypt to run the installssl.pl script after the first one. Only issue I had involved Drupal 7 sites; I had to completely take them offline and disable the .htaccess file to allow access to the ".well-known" directory. I also changed the ownership recursively to the site owner, and set the permissions to 755 (although I'm not entirely certain that was necessary). Oddly, there was no issue with Drupal 6 sites, although they have basically the same .htaccess file and same directory structure/permissions. Overall, installing was easy, and cPanel found the necessary files immediately. One odd glitch, though. After I installed the 1st one, I was no longer able to use the "Browse Certificates" function on the "Install an SSL Certificate on a Domain" page. The js "loading" popup appears over the grayed-out background, then it just disappears - leaving a non-functional page. Reloading the page and typing the domain name in the domain field worked to actually install the certs, and auto-discovery worked fine. Any ideas? I'm curious to see if the "Browse Certificates" functionality comes back after the next cPanel update

For the Drupal 7 sites, in the .htaccess, do you have a line that shows something like this:
RewriteRule "(^|/)." - [F]
If so, perhaps a line above that line, like this, might allow letsencrypt-auto to work for Drupal 7...
# Allow letsencrypt-auto access to the .well-known/acme-challenge directory... RewriteRule "^.well-known/acme-challenge" - [L]
0
Spork Schivago

February 23, 2016 17:20
The problem I see with the above posted fix (if it works for you) is that .htaccess can get over-written any time Drupal is updated. You'd have to find away to preserve the .htaccess file when you upgrade or try to automate the line always getting inserted. I do believe the Drupal developers are working on a patch to allow stuff like letsencrypt-auto to work. Support RFC 5785 by whitelisting the .well-known directory [#2408321] | Drupal.org
0
bhargav

February 24, 2016 04:47
Hello bhargav. Have you already generated the SSL certs for the various services? You know, whm.yourdomain.com, cpanel.yourdomain.com, webmail.yourdomain.com, etc?

Im accessing my accounts at yourdomain.com/whm, yourdomain.com/cpanel, yourdomain.com/webmail which redirects me to domain.com/2083 and so on. The subdomain service urls are throwing a name resolution error.
0
Spork Schivago

February 25, 2016 00:36
Could you paste the error message you're getting and the command you run? You can replace your real e-mail address and real domain names with fake stuff if you'd like. Also, have you tried creating the .well-known/acme-challenge/test file and making sure you can go to yourdomain.com/whm/.well-known/acme-challenge/test (for example)?
0
Jose A. G.

March 03, 2016 10:32
Hello, I do not like hard code root password at script.
my $auth = "Basic " . MIME::Base64::encode( $user . ":" . $pass );
I want to change it for some thing similar to hash method used here: digitz.org/blog/lets-encrypt-cpanel-script/ (It is PHP and I want to write it in PERL)
my $hash_file = "/root/.accesshash"; my $hash_WHM; open(my $hashfh, '<', $hash_file) or die "cannot open file $hash_file"; { local $/; $hash_WHM = <$hashfh>; } close($hashfh); $hash_WHM =~ s/\r\n//g; my $auth = "WHM root:" . $hash_WHM;
Do you think this line is well formed? Do you suggest a better wat for sanitize the string?
$hash_WHM =~ s/\r\n//g;
I will appreciate if you can give me any advice. [EDIT]Im getting Access Denied:
{"cpanelresult":{"apiversion":"2","error":"Access denied","data":{"reason":"Access denied","result":"0"},"type":"text"}}
I am confused with apiversion: 2, but the script provided uses: installssl?api.version=1 Perhaps I am using an updated WHM not compatible? [EDITED] Thanks.
0
Jose A. G.

March 03, 2016 11:35
I fixed the problem, I share my working modified version of the script. Remember to modify $hash with your accesshash. If your system has no .accesshash file feel free to Google and solve it in 30 seconds :-)
#!/usr/local/cpanel/3rdparty/bin/perl use strict; use LWP::UserAgent; use LWP::Protocol::https; use MIME::Base64; use IO::Socket::SSL; use URI::Escape; my $user = "root"; my $hash = "******CONTENT OF THE FILE /root/.accesshash ************"; $hash =~ s/\n//g; my $auth = "WHM root:" . $hash; my $ua = LWP::UserAgent->new( ssl_opts => { verify_hostname => 0, SSL_verify_mode => 'SSL_VERIFY_NONE', SSL_use_cert => 0 }, ); my $dom = $ARGV[0]; my $certfile = "/etc/letsencrypt/live/$dom/cert.pem"; my $keyfile = "/etc/letsencrypt/live/$dom/privkey.pem"; my $cafile = "/etc/letsencrypt/live/bundle.txt"; my $certdata; my $keydata; my $cadata; open(my $certfh, '<', $certfile) or die "cannot open file $certfile"; { local $/; $certdata = <$certfh>; } close($certfh); open(my $keyfh, '<', $keyfile) or die "cannot open file $keyfile"; { local $/; $keydata = <$keyfh>; } close($keyfh); open(my $cafh, '<', $cafile) or die "cannot open file $cafile"; { local $/; $cadata = <$cafh>; } close($cafh); my $cert = uri_escape($certdata); my $key = uri_escape($keydata); my $ca = uri_escape($cadata); my $request = HTTP::Request->new( POST => "https://127.0.0.1:2087/json-api/installssl?api.version=1&domain=$dom&crt=$cert&key=$key&cab=$ca" ); $request->header( Authorization => $auth ); my $response = $ua->request($request); print $response->content; # Install the SSL certificate for the FTP service print "\n\nAttempting to install the SSL certificate for the FTP service...\n"; my $request = HTTP::Request->new( POST => "https://127.0.0.1:2087/json-api/install_service_ssl_certificate?api.version=1&service=ftp&crt=$cert&cabund$ $request->header( Authorization => $auth ); my $response = $ua->request($request); print $response->content; # Install the SSL certificate for the exim service print "\n\nAttempting to install the SSL certificate for the exim service...\n"; my $request = HTTP::Request->new( POST => "https://127.0.0.1:2087/json-api/install_service_ssl_certificate?api.version=1&service=exim&crt=$cert&cabun$ $request->header( Authorization => $auth ); my $response = $ua->request($request); print $response->content;
This version of the script add SSL cert to FTP and EXIM as suggested at comment 54.
0
3awh

March 09, 2016 03:09
I followed the First post install worked great for my other 2 wordpress installs. OS is CentOS 6.6 install was a snap on the server then installing the cert for the first 2 sites went great. the last site not so great. when I put in
https://domain.com
in the url in chrome its a white page with
SSL connection error ERR_SSL_PROTOCOL_ERROR firefox Secure Connection Failed An error occurred during a connection to www.example.net. Peer reports it experienced an internal error. (Error code: ssl_error_internal_error_alert) The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Please contact the website owners to inform them of this problem.

http://www.domain.com
works. at first I changed the urls and was the same thing. Not sure how to proceed
0
3awh

March 09, 2016 17:38
How do I completly remove certs I have tried ./letsencrypt revoke --cert-path /etc/letsencrypt/archives/webmasteroncall.net/cert.pem/ got letsencrypt: error: argument --cert-path: No such file or directory then I tried ./letsencrypt revoke --cert-path /etc/letsencrypt/live/webmasteroncall.net/cert.pem/ got back Version: 1.1-20080819 Version: 1.1-20080819 At this point I like to remove everything. and Go with the Paid Cpanel plugin so all my users can use Lets Encrypt and it easier to setup for each domain. Stuck at this please help
0
bellwood

March 10, 2016 17:43
Is there a reason the head of this thread is still telling people to put their root password in clear text?
my $accesshash; my $access_hash_file = '/root/.accesshash'; sysopen (my $access_hash_file_fh, $access_hash_file, O_RDONLY) or die "unable to open root_access_hash_file $!\n"; while (<$access_hash_file_fh>) { $accesshash .= $_; } close ($access_hash_file_fh); $accesshash =~ s/\n//g; my %opts = @ARGV; my $username = $opts{'user'}; my $auth = "WHM root:" . $accesshash; $ENV{PERL_LWP_SSL_VERIFY_HOSTNAME}=0; my $ua = LWP::UserAgent->new; my $request = HTTP::Request->new( GET => "THE API CALL YOU NEED TO MAKE" ); $request->header( Authorization => $auth ); my $response = $ua->request($request); print $response->content;
Suggesting users store their root password in clear text is a huge no-no
0
davidpbj

March 19, 2016 10:46
Thanks for the directions, this is awesome!!
0
challgren

March 22, 2016 15:14
Instead of requiring a perl script to install the certs why not just call whmapi1 that way no passwords or access hashes have to be installed
0

Please sign in to leave a comment.

Comments

Didn't find what you were looking for?