I appear to be having a couple of issues with my ISPconfig and letsencrypt configuration. The question 1st I have is, can I create a subdomain in ISPconfig such as test.example.com and only have a cname dns record for * to example.com and an A record for example.com to my ip address. Will this be sufficient validation for letencrypt or do I need an A record for each subdomain I want to use? I tried setting up my own dns server but turns out my isp is blocking port 53 so had to bail on that idea. The 2nd question or problem is a little more complicated, I best explain my setup first. I have 3 domains registered. matthewobrn.com meldp.com meldp.com.au all of them have dns records as follows: Code: meldp.com. A 3600 122.151.149.134 * CNAME 3600 meldp.com. meldp.com. MX 3600 mail.meldp.com. 10 meldp.com. NS 3600 ns1.netregistry.net. meldp.com. NS 3600 ns2.netregistry.net. meldp.com. NS 3600 ns3.netregistry.net. When I create a website in ISPconfig for matthewobrn.com with a ssl cert from letsencrypt it works. Then I create a site for meldp.com also with a ssl cert from letsencrypt and when I try to view the page is serves the ssl cert for matthewobrn.com The same for meldp.com.au. If I create a subdomain as a website such as test.matthewobrn.com letsencrypt fails. Here is the letsencrypt log for test.matthewobrn.com: Code: 2016-08-27 03:49:14,521:DEBUG:certbot.main:Root logging level set at 30 2016-08-27 03:49:14,525:INFO:certbot.main:Saving debug log to /var/log/letsencrypt/letsencrypt.log 2016-08-27 03:49:14,528:WARNING:certbot.cli:You are running with an old copy of letsencrypt-auto that does not receive updates, and is less reliable than more recent versions. We recommend upgrading to the latest certbot-auto script, or using native OS packages. 2016-08-27 03:49:14,529:DEBUG:certbot.main:certbot version: 0.8.1 2016-08-27 03:49:14,529:DEBUG:certbot.main:Arguments: ['-n', '--text', '--agree-tos', '--expand', '--authenticator', 'webroot', '--server', 'https://acme-v01.api.letsencrypt.org/directory', '--rsa-key-size', '4096', '--email', '[email protected]', '--domains', 'test.matthewobrn.com', '--webroot-path', '/usr/local/ispconfig/interface/acme'] 2016-08-27 03:49:14,533:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#webroot,PluginEntryPoint#null,PluginEntryPoint#manual,PluginEntryPoint#standalone) 2016-08-27 03:49:14,535:DEBUG:certbot.plugins.selection:Requested authenticator webroot and installer None 2016-08-27 03:49:14,555:DEBUG:certbot.plugins.selection:Single candidate plugin: * webroot Description: Place files in webroot directory Interfaces: IAuthenticator, IPlugin Entry point: webroot = certbot.plugins.webroot:Authenticator Initialized: <certbot.plugins.webroot.Authenticator object at 0xb5fa6910> Prep: True 2016-08-27 03:49:14,559:DEBUG:certbot.plugins.selection:Selected authenticator <certbot.plugins.webroot.Authenticator object at 0xb5fa6910> and installer None 2016-08-27 03:49:15,944:DEBUG:certbot.main:Picked account: <Account(8673582473deb8f96d8dff55f84f5522)> 2016-08-27 03:49:15,954:DEBUG:root:Sending GET request to https://acme-v01.api.letsencrypt.org/directory. args: (), kwargs: {} 2016-08-27 03:49:15,972:INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org 2016-08-27 03:49:18,296:DEBUG:requests.packages.urllib3.connectionpool:"GET /directory HTTP/1.1" 200 280 2016-08-27 03:49:18,302:DEBUG:root:Received <Response [200]>. Headers: {'Content-Length': '280', 'Expires': 'Sat, 27 Aug 2016 03:49:14 GMT', 'Boulder-Request-Id': 'oXlxU0zagJqnOvVTqofeNM2_IRayhsUknH-nJt0Szd4', 'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx', 'Connection': 'keep-alive', 'Pragma': 'no-cache', 'Cache-Control': 'max-age=0, no-cache, no-store', 'Date': 'Sat, 27 Aug 2016 03:49:14 GMT', 'X-Frame-Options': 'DENY', 'Content-Type': 'application/json', 'Replay-Nonce': 'R3jp8PPQbneE6K7jXmHn0PX3bdTA-A7eRqQ3-WShVfA'}. Content: '{\n "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz",\n "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert",\n "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg",\n "revoke-cert": "https://acme-v01.api.letsencrypt.org/acme/revoke-cert"\n}' 2016-08-27 03:49:18,304:DEBUG:acme.client:Received response <Response [200]> (headers: {'Content-Length': '280', 'Expires': 'Sat, 27 Aug 2016 03:49:14 GMT', 'Boulder-Request-Id': 'oXlxU0zagJqnOvVTqofeNM2_IRayhsUknH-nJt0Szd4', 'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx', 'Connection': 'keep-alive', 'Pragma': 'no-cache', 'Cache-Control': 'max-age=0, no-cache, no-store', 'Date': 'Sat, 27 Aug 2016 03:49:14 GMT', 'X-Frame-Options': 'DENY', 'Content-Type': 'application/json', 'Replay-Nonce': 'R3jp8PPQbneE6K7jXmHn0PX3bdTA-A7eRqQ3-WShVfA'}): '{\n "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz",\n "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert",\n "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg",\n "revoke-cert": "https://acme-v01.api.letsencrypt.org/acme/revoke-cert"\n}' 2016-08-27 03:49:18,312:WARNING:certbot.main:Renewal conf file /etc/letsencrypt/renewal/meldp.com.au.conf is broken. Skipping. 2016-08-27 03:49:18,328:DEBUG:certbot.main:Traceback was: Traceback (most recent call last): File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/main.py", line 237, in _find_duplicative_certs candidate_lineage = storage.RenewableCert(renewal_file, cli_config) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/storage.py", line 242, in __init__ "file reference".format(self.configfile)) CertStorageError: renewal config file {} is missing a required file reference 2016-08-27 03:49:18,331:WARNING:certbot.main:Renewal conf file /etc/letsencrypt/renewal/meldp.com.conf is broken. Skipping. 2016-08-27 03:49:18,333:DEBUG:certbot.main:Traceback was: Traceback (most recent call last): File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/main.py", line 237, in _find_duplicative_certs candidate_lineage = storage.RenewableCert(renewal_file, cli_config) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/storage.py", line 242, in __init__ "file reference".format(self.configfile)) CertStorageError: renewal config file {} is missing a required file reference 2016-08-27 03:49:18,353:DEBUG:root:Requesting fresh nonce *****HAD TO REMOVE LOG LINES AS POST WAS TOO LONG***** 2016-08-27 03:49:24,314:INFO:certbot.reporter:Reporting to user: The following errors were reported by the server: Domain: test.matthewobrn.com Type: unauthorized Detail: Invalid response from http://test.matthewobrn.com/.well-known/acme-challenge/GXRXGqdPHRddC2Ri_8WCKPaxYMncXl0hXxBls_ieHkM: "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <ht" To fix these errors, please make sure that your domain name was entered correctly and the DNS A record(s) for that domain contain(s) the right IP address. 2016-08-27 03:49:24,316:INFO:certbot.auth_handler:Cleaning up challenges 2016-08-27 03:49:24,317:DEBUG:certbot.plugins.webroot:Removing /usr/local/ispconfig/interface/acme/.well-known/acme-challenge/GXRXGqdPHRddC2Ri_8WCKPaxYMncXl0hXxBls_ieHkM 2016-08-27 03:49:24,320:INFO:certbot.plugins.webroot:Unable to clean up challenge directory /usr/local/ispconfig/interface/acme/.well-known/acme-challenge 2016-08-27 03:49:24,321:DEBUG:certbot.plugins.webroot:Error was: [Errno 39] Directory not empty: '/usr/local/ispconfig/interface/acme/.well-known/acme-challenge' 2016-08-27 03:49:24,336:DEBUG:certbot.main:Exiting abnormally: Traceback (most recent call last): File "/root/.local/share/letsencrypt/bin/letsencrypt", line 11, in <module> sys.exit(main()) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/main.py", line 744, in main return config.func(config, plugins) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/main.py", line 555, in obtain_cert _, action = _auth_from_domains(le_client, config, domains, lineage) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/main.py", line 94, in _auth_from_domains lineage = le_client.obtain_and_enroll_certificate(domains) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/client.py", line 276, in obtain_and_enroll_certificate certr, chain, key, _ = self.obtain_certificate(domains) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/client.py", line 247, in obtain_certificate self.config.allow_subset_of_names) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/auth_handler.py", line 74, in get_authorizations self._respond(resp, best_effort) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/auth_handler.py", line 131, in _respond self._poll_challenges(chall_update, best_effort) File "/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/certbot/auth_handler.py", line 195, in _poll_challenges raise errors.FailedChallenges(all_failed_achalls) FailedChallenges: Failed authorization procedure. test.matthewobrn.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://test.matthewobrn.com/.well-known/acme-challenge/GXRXGqdPHRddC2Ri_8WCKPaxYMncXl0hXxBls_ieHkM: "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <ht" I followed the perfect server setup for Debian Jessie and ISPConfig 3.1. Thanks for any help.
The concept is sound, but I don't know if letsencrypt specifically will work that way. Get letsencrypt working "normally" then it should be pretty easy to test (and report here, if you would). Make sure the SNI checkbox is enabled in ispconfig, and check the IP addr in your vhost settings, make sure they all use either '*" or the ip addr, but don't mix the two or you get some unexpected results. Hmm, maybe that answers your first question. Try adding a DNS record for test.matthewobrn.com (ie. don't rely on the wildcard dns record) and see if that changes. Also in your output there are these, which might be worth looking in to:
So a little more information. Firstly, I have managed to solve the majority of the issues I was having. I installed another instance of the perfect server on a vmware workstation. I ran all of the same tests on this using the same domain names and urls. I also created the same websites in ISPconfig and tried issuing ssl certs from letsencrypt. Everything worked perfectly. Baring in mind this was two days after following the same tutorial on my Banana Pi M3. The only main difference is the architecture Arm64 vs Armv71. I did however notice a version difference between the two. Arm64 was ICPConfig 3.1dev and Armv71 was ISPConfig 3.1rc1 (I think). I tried running: Code: root@barrys:/etc/php5/cgi# ispconfig_update.sh -------------------------------------------------------------------------------- _____ ___________ _____ __ _ |_ _/ ___| ___ \ / __ \ / _(_) | | \ `--.| |_/ / | / \/ ___ _ __ | |_ _ __ _ | | `--. \ __/ | | / _ \| '_ \| _| |/ _` | _| |_/\__/ / | | \__/\ (_) | | | | | | | (_| | \___/\____/\_| \____/\___/|_| |_|_| |_|\__, | __/ | |___/ -------------------------------------------------------------------------------- >> Update Please choose the update method. For production systems select 'stable'. WARNING: The update from GIT is only for development systems and may break your current setup. Do not use the GIT version on servers that host any live websites! Note: Update all slave server, before you update master server. Select update method (stable,git-stable,git-master) [stable]: There are no updates available for ISPConfig 3.1rc1 So I put this down to the different architectures. (my first mistake) I began investigating if the letsencrypt url http://test.matthewobrn.com/.well-known/..... was actually being served to the internet when the authenication scripts were being run. It turns out they were not. I looked at the vhost serving the files "ispconfig.vhost" in the /etc/apache2/sites-avialible/ and noticed a big difference between the ones on my Banana Pi and the vmware workstation. The 3.1dev vesion had: Code: Alias /.well-known/acme-challenge /usr/local/ispconfig/interface/acme/.well-known/acme-challenge <Directory /usr/local/ispconfig/interface/acme/.well-known/acme-challenge> Require all granted </Directory> Where as the 3.1rc1 had something like this: Code: <IfModule mod_headers.c> <LocationMatch "/.well-known/acme-challenge/*"> Header set Content-Type "text/plain" </LocationMatch> </IfModule> When I changed the files to the newer version it seemed to fix everything. Or so I thought. After I changed some other settings around in the ISPConfig control panel things started going awry again. I eventually decided that it was time for a fresh install of ISPConfig so I downloaded ran the following: Code: cd /tmp wget -O ISPConfig-3.1-beta.tar.gz https://git.ispconfig.org/ispconfig/ispconfig3/repository/archive.tar.gz?ref=stable-3.1 tar xfz ISPConfig-3.1-beta.tar.gz cd ispconfig3-stable-3.1* cd install php -q uninstall.php .... php -q install.php This updated to ISPConfig to 3.1dev on the banana pi and everything works great with regards to the ssl certs and letsencrypt. Once the server was configured correctly and all the subdomains had no aliases of there own it worked great. Once I change ISP's and have my own dns running I will set up A records for all the domains. Right now I'm limited to 10 dns record changes per year per domain. (A pain in the ass i know) I can't seem to find the sni checkbox in ispconfig. I think it is probably already enabled as its all working. Interesting you mention about the '*' or a specific ip address. During my fault finding I found is that in the Apache2 documentation it mentions that there is no difference between: Code: <VirtualHost _default_:80> ... </VirtualHost> and <VirtualHost *:80> ... </VirtualHost> This is not true. I had a website setup called matthewobrn.com and enabled the default alias to be * This was so http://anything.matthewobrn.com would be directed to the http://matthewobrn.com site. I couldn't get it working. http://anything.matthewobrn.com kept being directed to the default apache index.html at /var/www/html. But I did notice the https://anything.matthewobrn.com did navigate to https://matthewobrn.com Investigating the vhost files for 000-default.conf and defaul-ssl.conf the only main difference was the *:80 and _default_:80 once I changed to *:80 in the non ssl file everything worked beautifully. I did try adding an A DNS record for one of the domains just as a test with no avail. Now onto the next problem, http://mysite.com/phpmyadmin isn't working. I can't find any reference to it in the vhost files or /etc/apache2/conf files. From what I have read there should be a system link to it in the /etc/apache2/conf -> /etc/phpmyadmin/apache.conf Can anyone confirm this before I break my server again!
You mix up ISPConfig versions here. You tried to downgrade ISPConfig 3.1rc1 to ISPConfig 3.0.5.4p9 as ISPConfig stable is 3.0.5.4p9, so the installer told you that there i no newer version, ISPConfig 3.1 has not been released yet and therefore can not be stable. If you ant to update a beta or RC release, chose git-stable. The symlink gets created by the phpmyadmin apt installer. if it is missing, then you did not selected apache2 during install. selecting means moving the cursor to the menu point with [tab] and then activating it with [space]. You can rerun the step with: dpkg-reconfigure phpmyadmin
Cheers for that, should have realised. Something to look out for in the future. On a side note, who maintains the tutorial pages? It's only a type in the title, probably not even worth mentioning. Step 8 Step 10 And for some reason phpMyAdmin must not have finished correctly as the symlink is missing. I ran the command and it worked beautifully. Everything is now working! Time to do a dd backup onto my sd-card.
