Installation help for a non-technical person?

serverco, I ran all the commands in your previous post up to “~/getssl -c domain.com” via the MacOS Terminal. I am now editing “getssl.cfg”. The following lines are the only lines not commented:

CA="https://acme-staging.api.letsencrypt.org"

ACCOUNT_EMAIL="<my-email-address>"
SANS="www.<my-domain>.com"
ACL=('/home/<my-username>/public_html/.well-known/acme-challenge')
USE_SINGLE_ACL="true"
RELOAD_CMD="${HOME}/cpanel_cert_upload <my-domain>.com"
ACCOUNT_KEY_LENGTH=4096
ACCOUNT_KEY="/home/<my-username>/.getssl/account.key"
PRIVATE_KEY_ALG="rsa"

RENEW_ALLOW="30"

SERVER_TYPE="https"
CHECK_REMOTE="true"

I have not run “~/getssl -a” yet because I have these 3 questions first…

(1) What is “.well-known/acme-challenge”? When I use my FTP client to access /public_html/ I do not see “well-known” there at all.

(2) Does everything else in my *.cfg file above look okay?

(3) I have a 2nd domain hosted on the same shared web server. It appears in cPanel’s “Addon Domains” ( /domains/<my-other-domain.jp>/public_html ) and “Subdomains” ( my-other-domain.my-domain.com ). How do I add a certificate for this? Does it entail merely changing the getssl.cfg content to the following?

CA="https://acme-staging.api.letsencrypt.org"

ACCOUNT_EMAIL="<my-email-address>"
SANS="www.<my-domain>.com,<my-other-domain.jp>"
ACL=('/home/<my-username>/public_html/.well-known/acme-challenge'
     '/home/<my-username>/domains/<my-other-domain.jp>/public_html/.well-known/acme-challenge')
USE_SINGLE_ACL="true"
RELOAD_CMD="${HOME}/cpanel_cert_upload <my-domain>.com"
ACCOUNT_KEY_LENGTH=4096
ACCOUNT_KEY="/home/<my-username>/.getssl/account.key"
PRIVATE_KEY_ALG="rsa"

RENEW_ALLOW="30"

SERVER_TYPE="https"
CHECK_REMOTE="true"

Thanks,

James

The .well-known folder will be created if it doesn't exist ( or you can create it yourself if you prefer).

Yes. This will get a cert from the "staging" or "test" server, which is good for testing, although not a valid cert. If the test works change the CA line to CA="https://acme-v01.api.letsencrypt.org" for the live server.

Close, since these are different ACL locations, you can't use the single ACL ( USE_SINGLE_ACL="true" )

You may also want to include "www.<my-other-domain.jp>"

CA="https://acme-staging.api.letsencrypt.org"

ACCOUNT_EMAIL="<my-email-address>"
SANS="www.<my-domain>.com,<my-other-domain.jp>,www.<my-other-domain.jp>"
ACL=('/home/<my-username>/public_html/.well-known/acme-challenge'
        '/home/<my-username>/public_html/.well-known/acme-challenge'
'/home/<my-username>/domains/<my-other-domain.jp>/public_html/.well-known/acme-challenge'
     '/home/<my-username>/domains/<my-other-domain.jp>/public_html/.well-known/acme-challenge')
RELOAD_CMD="${HOME}/cpanel_cert_upload <my-domain>.com"
ACCOUNT_KEY_LENGTH=4096
ACCOUNT_KEY="/home/<my-username>/.getssl/account.key"
PRIVATE_KEY_ALG="rsa"

You now have 4 ACL lines ( for domain.com, www.domain.com, my-other-domain.jp, www.my-other-domain.jp

serverco:

ACL=('/home/<my-username>/public_html/.well-known/acme-challenge'
     '/home/<my-username>/public_html/.well-known/acme-challenge'
     '/home/<my-username>/domains/<my-other-domain.jp>/public_html/.well-known/acme-challenge'
     '/home/<my-username>/domains/<my-other-domain.jp>/public_html/.well-known/acme-challenge')

You put duplicates of two lines in the ACL as shown above for some reason. Why?

Also, if there are 4 lines in ACL, shouldn’t there also be 4 domains in SANS? (You have 3 in SANS.)

Another thing, the actual path to my second domain on my server is displayed without “www” so if I add “www.” to that domain in the path I write into ACL, wouldn’t that be wrong? And the actual server path to my primary domain is: /home/(my-username)/public_html/. How do we know “www” is even needed or used, as per that server path? Furthermore, I don’t understand how you would add “www.” in that particular path where the domain name does not even appear.

I’m pretty confused at this point, but it would seem the following should be correct (but I still am leery about adding that “www” since it does not exist in the actual server path):

SANS="<my-domain>.com,<my-other-domain.jp>,www.<my-other-domain.jp>"
ACL=('/home/<my-username>/public_html/.well-known/acme-challenge'
     '/home/<my-username>/domains/<my-other-domain.jp>/public_html/.well-known/acme-challenge'
     '/home/<my-username>/domains/www.<my-other-domain.jp>/public_html/.well-known/acme-challenge')

Thanks,

James

You have 4 "domains" that you are requesting on the certificate. the main domain, and 3 alternative names, hence there needs to be an ACL for each of those. For your domains the ACL is the same for mydomain.com and www.mydomain.com hence there are duplicates.

I don't understand fully what you mean here. For the "path" on the server ( i.e. the ACL) we didn't include a www, because it's not needed. If you mean that you don't use "www.my-other-domain.com" you only have "my-other-domain.com" then it depends really if any user could ever use "www.my-other-domain.com" and perhaps it gets redirected to www.my-other-domain.com. If so, then it's best to include it in the cert.

In your last example, you include "my-domain.com" - you don't need that as it's already there as the "domain", so shouldn't be an "alternative domain".

Okay. I left the duplicates in the cfg file and saved it. I then ran the installer script via the Terminal:

~/getssl -a

Here is what I then saw in the Terminal:

Check all certificates
<mydomain>.com: Certificate on remote domain does not match, ignoring remote certificate
creating account key /home/<my-username>/.getssl/account.key
creating domain key - /home/<my-username>/.getssl/account.key
Generating RSA private key, 4096 bit long modulus
............++
.......................................................................++
e is 65537 (0x10001)
/home/<my-username>/getssl: line 632: -4: substring expression < 0
creating domain key - /home/<my-username>/.getssl/<my-domain>.com/<my-domain>.com.key
Generating RSA private key, 4096 bit long modulus
.....++
....................................................................................................................................................................................................................++
e is 65537 (0x10001)
/home/<my-username>/getssl: line 632: -4: substring expression < 0
creating domain csr - /home/<my-username>/.getssl/<my-domain>.com/<my-domain>.com.csr
Registering account
Registered
Verify each domain
Verifying <my-domain>.com
copying challenge token to /home/<my-username>/public_html/.well-known/acme-challenge/c7Ut06A5YA1d1ePqCz0xG_iSXCmgGI-0aoe9VU3rRzc
Verified <my-domain>.com
Verifying ghostotter.com
copying challenge token to /home/<my-username>/public_html/.well-known/acme-challenge/VWCgZIDqd6WmAYBHK2RBQxbwrvOlD8S0bk4AMwQozH4
getssl: for some reason could not reach http://ghostotter.com/.well-known/acme-challenge/VWCgZIDqd6WmAYBHK2RBQxbwrvOlD8S0bk4AMwQozH4 - please check it manually

I tried typing https://www.(my-domain).com in Safari, but Safari still gives me the usual “Can’t verify the identity of the website. This certificate for this website is invalid” error dialog when I do that. And when I then click the “Show Certificate” button in that error dialog, it says the certificate is from ghostotter.com but that there is a host name mismatch.

What must I do at this point?

I think it’s time to use your real domain names and real username (you can email me getssl at serverco.com if you prefer not to paste it here ( or private message me )

I would like to extend my personal and sincere thanks to serverco, who very kindly and tirelessly has provided me with detailed specifics via PM to help me get up and running with his excellent script. The only caveat pertains to my web host provider – because my sites are hosted on a shared server, they must use “WHM” to modify a server setting every time a new certificate is issued. That means during initial setup and each time the CRON job refreshes the certificates, I must contact them via ticket and they then must make the same change (whatever that is) in WHM. I’ve encouraged them to install the Let’s Encrypt cPanel plugin, but since they prefer to sell their “premium” certificates, they may be reluctant to offer the plugin even though it would save them time.

At any rate, I now have a question for the rest of you following this thread.

I am thinking about forcing use of HTTPS via .htaccess. That way if people click links to our site (from Google or other sites), they would get HTTPS rather than HTTP. Does the following code seem reasonably good to use for that?

RewriteEngine On 
RewriteCond %{HTTP_HOST} ^mydomain\.com [NC]
RewriteCond %{SERVER_PORT} 80 
RewriteRule ^(.*)$ https://www.mydomain.com/$1 [R,L]

RewriteCond %{HTTP_HOST} ^mydomain2\.jp [NC]
RewriteCond %{SERVER_PORT} 80 
RewriteRule ^(.*)$ https://mydomain2.jp/$1 [R,L]

RewriteCond %{HTTP_HOST} ^install.mydomain\.com [NC]
RewriteCond %{SERVER_PORT} 80 
RewriteRule ^(.*)$ https://install.mydomain.com/$1 [R,L]

Thank you,

James

Well, I guess none of you are well versed enough in .htaccess to advise me!

Here is what I am using, which seems to work well to switch HTTP requests to HTTPS:

# Enable Rewrite feature:
RewriteEngine On

# Ensure the connection is NOT already HTTPS:
RewriteCond %{HTTPS} !=on

# Rewrite only on this domain (with or without the www in front):
RewriteCond %{HTTP_HOST} ^(www\.)?mydomain\.com [NC]

# Restrict HTTP-to-HTTPS rewrites on port 80 (which is used for HTTP):
RewriteCond %{SERVER_PORT} 80

# Redirect users from their original location to the same location but using HTTPS.
# EXAMPLE:  http://www.example.com/foo/ redirects to https://www.example.com/foo/
RewriteRule ^(.*)$ https://mydomain.com/$1 [R=301] 

But honestly, in searching the web, I see there are a variety of ways to construct the closing “RewriteRule”:

RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [QSA,R=301,L]

RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R=301,L]

RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Not sure what is best, really. But I decided to use rewrites to my specific domain because I was unsure if “rewrite all HTTP requests to HTTPS” would be a problem, in light of the fact I have external links to other sites embedded on various pages of my site. So if someone clicks on one of those links, I obviously would not want HTTP converted to HTTPS.

I also read someone claim that if you have .htaccess files in subdirectories then the HTTP to HTTPS rewrites would be ignored without using the following line in the root .htaccess file:

# Prevent the rule from being overrided by .htaccess files in subdirectories:
RewriteOptions InheritDownBefore

But I don’t use that line at all, and despite having .htaccess files in subdirectories, I am seeing HTTP redirect to HTTPS just fine.

But again, if anyone reading this has any thoughts or suggestions, I am all ears.

Thanks.

UPDATE: Some people I’ve asked to test our site using HTTPS have said they can no longer download files (mostly PDFs) using their Android phones. This could have something to do with TLS version support depending on the Android OS version. So I must ask you, is there anything I can do in my .htaccess file to resolve such problems?

That's not what mod_rewrite does. It rewrites URLs on your site (in the sense of "where they are understood to point to"), but not HTML content.

It would be good to look at your site with a tool like

which should be able to tell you something about client compatibility and whether there is something unusual there. If it's a cryptographic compatibility problem, you can try generating a configuration with

https://mozilla.github.io/server-side-tls/ssl-config-generator/

(perhaps using the "Old" profile if you know you need to support older clients). The results of this would generally go into your main Apache configuration file, not .htaccess.

So what would be the point of having this conditional line in the .htaccess file then?

# Rewrite only on this domain (with or without the www in front):
RewriteCond %{HTTP_HOST} ^(www\.)?mydomain\.com [NC]

In other words, why use that RewriteCond to make the Rewrite "domain specific"?

Also, such would seem to mean that any of the following RewriteRules would work the same as the rule I am using now, right?

RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [QSA,R=301,L]

RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R=301,L]

RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Yes, I had already run that exact test on my sites. My sites score an A- with that test. SSL2 and SSL3 are OFF, but TLS1.0/1.1/1.2 (all 3) are enabled on my site (for compatibility). Despite the fact TLS1.0 is enabled though, my Japanese Android 4.1.1 users (who mostly use the Yahoo browser on Android) are reporting that although they can see all the content of web pages in my sites while using HTTPS, they get errors when trying to download PDF files, which I find rather confusing. Any thoughts?

If it's a cryptographic compatibility problem, you can try generating a configuration with

https://mozilla.github.io/server-side-tls/ssl-config-generator/

(perhaps using the "Old" profile if you know you need to support older clients).  The results of this would generally go into your main Apache configuration file, not .htaccess.

My sites are hosting on a shared web server and my host provider does not allow me access to the Apache config file. I only have basic control by SSH and control by .htaccess.

Thanks,

James

It feels unlikely that you can affect this from .htaccess without being able to make general Apache configuration changes. However, it is weird that it fails for users in the wild after showing no apparent problems on SSL Labs, and also weird that it works for some parts of your site and not for others.

Can you find out anything about the exact error messages the users see, and can you suggest a particular pair of URLs on your site that do and don't show the error?

Hi schoen,

I was paid a visit yesterday by one of our Android users and saw the actual phone. There is in fact no error message whatsoever. When a link to a PDF on our HTTPS website is tapped on that Android 4.1.1 phone, from within the Yahoo browser, the PDF starts to download in the “Download Manager” app (because the silly Yahoo browser won’t display PDFs in-browser for some reason), and all the while PDF download status bar (within Download Manager) just keeps showing that it is downloading something, but nothing ever downloads and it doesn’t timeout either. It’s quite strange.

The user did say that he, like many Android users in Japan, has the latest version of a security app installed named Dr. Web light" installed:

But if we argue that anti-virus app is the culprit, why then were there no issues at all when our site was using HTTP exclusively? Would a switch to HTTPS cause an Anti-virus app on Android to filter out or block content? Seems strange that it would.

Thanks.

This can happen sometimes because sometimes antivirus software can intercept HTTP downloads (to scan them?) but not HTTPS downloads. I don't know if this is the case on the Android platform in particular or with Dr. Web Light in particular.

5 posts were split to a new topic: Permissions error when using getssl

I’m going to close this topic because each new person who’s using it has had a different problem or situation generally unrelated to the previous one. We would like people with different situations to start new topic threads on the forum.