Installing LetsEncrypt on a Mac OS X Client Server (Questions)


First, I would like to give my Thanks to everyone that participated in the development and education of LetsEncrypt.

I am testing the LetsEncrypt client application on my OS X Server. No, is not the Apple OS X Server, it is my own server built from scratch from two Macs. One is a backup server and the other is the production server. Both are running on OS X Mavericks. No, I am not upgrading until Apple get their thing together and show me that they can build a system that is as fast as Panther and as stylist as Mavericks. Any way, I got my certificates validated by running the LetsEncrypt client application and they are ready to be tested.

Right now I am only installing the certificate in one domain for testing.

I am intending to share my experience step by step on installing them later but first I have a question;

  • After my certificate validation, I end up with these certificates;

a. cert1.pem <--- This I know, is my CRT

b. chain1.pem or fullchain1.pem <--- This is my chain certificate and I can use one or the other but I read that is better to use the second one, fullchain1.pem

c. privkey1.pem <--- Here is my question; - Is this my server domain decrypted key?

Many Thanks!


This depends on your server software. With apache 2.2, you would need:

  • cert.pem for SSLCertificateFile
  • chain.pem for SSLCertificateChainFile

With apache 2.4, you can skip SSLCertificateChainFile and only need to use SSLCertificateFile with fullchain.pem (this file includes both cert.pem and chain.pem).
Check the documentation of your server software to figure out which files you need.

That's your private key, the "secret" piece of the puzzle. cert.pem, chain.pem and fullchain.pem are public and can be given to anyone, but privkey.pem contains the keys to the castle - whoever has this key can potentially decrypt all your traffic, etc.

With apache you would use this file with the SSLCertificateKeyFile directive.


Thank you soo much for your answer!
I am actually on Apache 2.4 and you are saying that I can just connect the fullchain.pem and that will take care of everything?
By the way, thanks for tell me so I don’t go on and expose my privkey.pem.

Here is my example configuration of my “httpd-vhosts.conf” conf;

# site virtual host SSL 443
<VirtualHost *:443>
DocumentRoot "/Users/serveruser/Sites"
SSLEngine on
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCACertificateFile "/etc/letsencrypt/live/"
    ErrorLog "/usr/local/apps/apache2/logs/error_log"
    TransferLog "/usr/local/apps/apache2/logs/access_log"
    CustomLog /usr/local/apps/apache2/logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

Do you think that will work fine?

You will need at least:

SSLCertificateFile /etc/letsencrypt/live/
SSLCertificateKeyFile /etc/letsencrypt/live/

(Note: Your config uses SSLCACertificateFile, this should be SSLCertificateFile without CA.)

If you want to go further down the rabbit hole, take a look at Mozilla’s guide on SSL, and their config generator. This will do a lot more than the minimal configuration you need to get basic HTTPS up and running.

1 Like

I performed a test and here are some logs I got so far.

apache config test fails, aborting
AH00526: Syntax error on line 218 of /usr/local/apps/apache2/conf/extra/httpd-vhosts.conf:
SSLCertificateKeyFile: file '/etc/letsencrypt/live/' does not exist or is empty
AH00526: Syntax error on line 218 of /usr/local/apps/apache2/conf/extra/httpd-vhosts.conf:
SSLCertificateKeyFile: file '/etc/letsencrypt/live/' does not exist or is empty 

Both “httpd-vhosts.conf” conf and httpd-ssl.conf are configured ok. The domain in question is not responding to https, only to http.

  • Any ideas?

Ps: I am on California time. Tomorrow I’ll return to continuing…

If your certs are named like the above, but failing with different name/location ex. /etc/letsencrypt/live/, then either your config hasn't been update, can't be read by apache (permissions issue), or you haven't restarted the service.

Verify the exact location and name of the certs, and confirm they show up in the *.conf files with the same name/location.

I think you have a confusion between the live and archive versions. The live versions are the ones that you’re supposed to use in your configuration files (because if you renew a cert they’ll be updated automatically to point to the new version). The live versions don’t have the numbers like fullchain1.pem, they should just say fullchain.pem and so on. So try removing the 1 from your configuration files and just using fullchain.pem and privkey.pem.

The numbers are part of the filenames in the archive directory, which we suggest not using directly. That’s where the various different historic versions go when a particular certificate is renewed, so that you can go back to (or revoke, or just refer to) an earlier version if that becomes necessary for some reason.

1 Like

Hello @StopSpazzing, and @schoen,

Thank you both for the instructions!

@StopSpazzing, I do restart the services on each change of the configuration files. However, Thanks for pointing that out! In regards to permissions, I was thinking about the same issue, however the LetsEncrypt configuration directories are owned by the “system” only. I also think these types of permissions could be a problem as Apache won’t be able to access the folder to read it’s content. So, we both have a point there!


You are absolutely right, Thanks also to point that out and I went back and changed the path string in both; “httpd-ssl.conf”, and “httpd-vhosts.conf” to point to;

SSLCertificateKeyFile “/etc/letsencrypt/live/”
SSLCACertificateFile “/etc/letsencrypt/live/”


However Apache refused to start and I think that goes back to @StopSpazzing in regards to permissions. In the logs it says;
[Mon Dec 28 09:27:00.586312 2015] [mpm_prefork:notice] [pid xxxxx] AH00169: caught SIGTERM, shutting down
AH00016: Configuration Failed

Starting Apache Web Server…
Exit code: 3
/usr/local/… : httpd could not be started
Syntax OK

So… I think we are going back to the permissions issue then!

Ok! Things I should tell you first!

The Server does have already a class2 Certificate for one of the ecommerce domain I am hosting. However, I think that is not relevant to the other Certificate here. If any of you think there are any conflicts in using 2 certificates for different domains with one single ip address, let me know?

Permissions: When I installed LetsEncrypt, it created the directories in the system on /etc/ with all permissions in place. Here is what is in place. Looking at the permissions, I encounter two issues;

  1. /var/logs/letsencrypt/ <— is owned by the system and no access. Therefore Console cannot read them neither do I.

  2. LetsEncrypt directory

a. accounts
b. archive
c. csr
d. keys
e. live <--- is owned by the system and no access. Therefore, I think even thou I have the Apache performing as root, with this type of permissions, Apache cannot read them. So, the permission on live directory needs to change to something like; (system: read & write, everyone: read only)
f. renewal

Let me know if my line of thought is going to the right direction so I can change the permissions!

Ps: I think I know what happened with the permissions. Home Brew, one of the LetsEncrypt requirements to install Python to generate the Certificates on the Mac OS System, only install as a client in the Admin User directory and not as Root SuperUser and I think that is the reason LetsEncrypt permissions got that way.

I tried to fix the permissions of the live directory and give another try. Still Apache refuses to start with “Syntax OK”.

Looking in the directory I see that all the certs have alias instead of the originals.

Tested the alias and found that is not pointing to the real certificate. Actually is not working at all.

I need some input now from you guys to find out what could be wrong.



Hi @ebonsi, do the real certs exist inside of your archive directory, or is archive somehow entirely empty? What do you have there?

Sorry to respond so late @schoen, I am going to change the permissions in the archive directory. But I think they are there! Just that, the alias is not working towards that direction.

update: The aliases are all working now!

Give me a moment! ... Yes they are all there!
I was thinking about the whole directory permissions; right now they are;

Here is how the permissions were before...

and I have opened the permissions this way;

...and I am wondering if the permissions could be different in a way that would work and improve security.
... because now they can be read by anyone. If you can read, you can open and copy and that could cause security issues. Or not?
-- What do you think?

Hi @ebonsi, we have a discussion on GitHub where we track development-related issues and bugs about this very question of permissions. It doesn’t seem like there’s a clear consensus about exactly what the permissions should be by default. The problem is that any set of permissions that we use will apparently break on some operating systems or in some server software. In this case it looks like you found that permissions that often worked OK on Linux systems didn’t work well on MacOS X.

Probably the long-term solution to this would be to have more operating system developers themselves choose security policies for their systems and then distribute appropriate Let’s Encrypt client software as part of the operating system (configured to respect the security policy for each OS).

The general problem is discussed here

among other places. If you have a GitHub acount, you can feel free to chime in there describing your experience with OS X. But I’m afraid we might not find a simple solution that works well for everybody.

I’m glad you were able to resolve the problem on your system, and sorry for the inconvenience that the defaults created for you.

1 Like

update: Ok! I changed the permissions so it will be more secure and still working.

I think with these permissions everything will be away from "snoopers" on the system, (if ever happen). I tested the alias and it works just fine. Then I went to test the Server and again got "Syntax OK" and the logs just say "Configuration Failed" and Apache refused to start.

Update: Ok! Before even posting my "httpd-ssl.conf" and my "httpd-vhosts.conf" files, I opened another threat at the LetsEncrypt GitHub Developer site with the title;
What would be the correct permissions for the LetsEncrypt directory on OS X?
What would be the correct permissions for the LetsEncrypt directory on OS X? · Issue #2076 · certbot/certbot · GitHub

As soon as that will be answered, I will test and continue to share the information if the test works! Thanks! E\

Here are the permissions I applied to the LetsEncrypted directory and I already tested one domain and it worked fine.

Since I tested the software ok, I am going to share how I installed and configured LetsEncrypt on my Server. So refer to the title:
Installing and Configuring LetsEncrypt on a Mac OS X Client Server

1 Like