If you want to go full throttle…
The Munki Wiki has some detailed instructions (and a script) to set up your own certificate authority and then issue (and revoke) client certificates:
Using Munki With SSL Client Certificates
If you want something secure but simple
If you want something a little bit simpler but not straight plain text with no authentication, another option is to enable SSL and couple it with basic authentication. This post will walk you through that process, using a Mac desktop Apache server (process is probably similar for Ubuntu or Windows Apache, but there may be small tweaks).
Use a real certificate
If your server is public-facing, you can use Let’s Encrypt to get a free proper certificate or if you can afford to buy a proper certificate, you can just pay for one and install it.
But if you don’t want to pay for a certificate and if your server is also not public-facing, you may want to go for a self-signed certificate, which can still have some security issues but is better than using plain text http.
Set up a self-signed certificate
On your Apache server, you’re going to create a self-signed certificate, which means it will be untrusted by pretty much any web browser when visiting https, but for Munki it will be fine as long as we put the .pem file in the right place.
Generate the server key:
openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout server.key -out server.crt
Answer the questions based on your organization’s details. If you’re unsure how to answer the questions, Using Munki With SSL Client Certificates actually goes into quite a bit of detail on what to answer and what to skip.
Create a .pem
Move the server.key and server.crt files and change ownership to root
sudo chown root:wheel /etc/apache2/server.key
sudo mv server.crt /etc/apache2
sudo chown root:wheel /etc/apache2/server.crt
Save the ca.pem file for later—your Munki clients will need that file.
Enable SSL on Apache
Edit the httpd.conf file while making a backup
Uncomment (remove the # from the beginning of) the following lines:
Save the file (Control-X).
Edit the httpd-ssl.conf file while making a backup
Edit the virtual host setup to reflect your actual setup. Here’s an example, but make sure you put in your actual details (don’t just copy and paste from below):
DocumentRoot “/Library/WebServer/Documents/munki_repo“
ServerName subdomain.domainname.org:443
ServerAdmin youremail@domainname.org
Save the file (Control-X)
Enable basic authentication
If your Munki repo isn’t in /Library/WebServer/Documents/munki_repo, feel free to adjust to your actual setup:
htpasswd -c .htpasswd munki
You’ll be prompted for a password (with no visual feedback—it is still being accepted and processed). Feel free to create as many usernames (not just munki) and passwords as you want. Probably best to start with just one to make sure everything’s working. Don’t forget this password, at least not until you get at least one client set up.
Go back and edit your httpd.conf file
Apparently you’re supposed to find the <Directory> section and add this after the existing configuration directives, but I put it in some random spot, and it still seemed to work. To be safe, you may want to put it where you’re supposed to, though:
<Directory “/Library/WebServer/Documents/munki_repo“>
AuthType Basic
AuthName “Authentication Required”
AuthUserFile /Library/WebServer/Documents/munki_repo/.htpasswd
Require valid-user
Order allow,deny
Allow from all
</Directory>
Save the file (Control-X).
Test your Apache config
Since you’ve been editing a couple of configuration files, make sure you didn’t make any syntax errors:
If that passes and says your syntax is okay, then restart the Apache service:
Set up your clients to use basic authentication
Okay. Remember how I said not to forget the password for basic authentication? Well, you need that password now. On your client you’ll be running a bunch of commands. Don’t save your commands for this session to the ~/.bash_history file:
Create a base 64–encoded username/password combo:
which should output something like
That last encoded bit will vary, obviously, based on the username and password you choose.
Write that to the “secret” (still readable by admins who escalate to root) Managed Installs .plist:
Also write the now-https location of your Munki repo:
If you’re going with a self-signed certificate, copy the ca.pem from your server to the client machine (in its desktop folder, for example). Then, on the client machine, move it to the appropriate place with the appropriate permissions:
sudo mv ~/Desktop/ca.pem /Library/Managed\ Installs/certs/
sudo chown -R root:wheel /Library/Managed\ Installs/certs
sudo chmod 700 /Library/Managed\ Installs/certs
sudo chown 600 /Library/Managed\ Installs/certs/ca.pem
If you have a proper certificate from Let’s Encrypt or another certificate authority, you don’t need this ca.pem file.
Finally, test it out and make sure everything works!
If it doesn’t work, try
to see if you can find out more details in the verbose output.
How secure is this?
All this secures is network traffic, so you’re not passing information in plain text. It also means random computers that just know the address of your repository can’t randomly access all the packages in your Munki repo.
But this does not secure against your actual users, especially if they have admin privileges on their machines (or have extended physical access to their machines, which—with a little know-how or Google Fu—is essentially root access).
To a certain extent, this may be a moot point if your Munki server isn’t public-facing, but it’s still a nice, small barrier to put up in case you have someone somehow get on your internal network and want to sniff around.
Acknowledgements
The instructions above I cobbled together based on instructions from these tutorials:
Leave a Reply