Step CA

02 May 2024 in Homelab / Stepca 2024-09-11

I think it would be nice to get rid of the pesky certificate warnings on my Proxmox and PBS GUI’s. There will be other benefits too that I can’t think of right now.

My plan was to write a bunch of neat Ansible playbooks to deploy the CA and manage certificates ongoing. Foolishly, I failed to check first if someone had already done this legwork which, of course, they had. You can find it on Ansible Galaxy here: maxhoesel.smallstep.

Some notes on my specific deployment and how I use Ansible to do this.

Ansible Repo Structure

├── Readme.md
├── collections
│   └── requirements.yml
├── roles
│   ├── step_ca
│   │   ├── Readme.md
│   │   ├── files
│   │   ├── tasks
│   │   │   ├── configure_ca.yml
│   │   │   └── main.yml
│   │   └── vars
│   │       └── main.yml # just has --> step_home_path: /etc/step-ca
│   ├── step_ca_provisioners
│       ├── tasks
│       │   ├── configure_acme.yml
│       │   └── main.yml
│       └── vars
│           └── main.yml # just has --> step_home_path: /etc/step-ca
├── step-distribute-ca-pve.yml
├── step-distribute-ca.yml
├── step-enrol-client.yml
├── step.yml

Step 1

Include the maxhoesel.smallstep collection in your requirements.yml for your Playbook.

collections:
- name: maxhoesel.smallstep

Step 2

Create a new role in the roles folder of your playbook called “step_ca”. This role will hold some pre-requistie binaries to install - well just one. The acl package.

- name: Install ACL package
  apt:
    name: acl
    update_cache: yes
    state: present

Step 3

Create a role for our step ca provisioners (ACME)

- name: Setup our ACME provisioner, forcing a CN and requiring EAB
  maxhoesel.smallstep.step_ca_provisioner:
    name: acme
    ca_config: /etc/step-ca/config/ca.json
    ca_url: https://step-ca.mgmt.etse.me
    type: ACME
    force_cn: yes
  register: acme

- name: Restart the Step CA Service 
  service:
    name: step-ca.service
    state: restarted
  when: acme.changed

Step 4

Create a playbook file step.yml which bootstraps the Internal CA.

---
- hosts: stepca
  become: yes
  roles:
    - { role: step_ca }
    - { role: maxhoesel.smallstep.step_ca }
    - { role: step_ca_provisioners }
  vars:
    step_ca_name: etse.me CA
    step_ca_dns: ""
    step_ca_address: :443
    step_ca_url: ""

Adding the new Internal CA into the Trusted Certiticate store

Create a playbook as below..

---
- hosts: debian,docker,ubuntu,lxc
  become: yes
  roles:
    - { role: maxhoesel.smallstep.step_bootstrap_host }
  vars:
    step_bootstrap_ca_url: https://step-ca.mgmt.etse.me
    # Use the fingerprint from the Root Certificate, not the Intermediate one.
    step_bootstrap_fingerprint:  # A variable holding the CA's fingerprint
    step_bootstrap_install_cert: true

Issue a certificate for an Internal Client

Certificate gets placed in the local certificate store.

---
- hosts: step_enrol
  become: yes
  roles:
    - { role: maxhoesel.smallstep.step_acme_cert }
  vars:
    step_bootstrap_ca_url: https://step-ca.mgmt.etse.me
    # Use the fingerprint from the Root Certificate, not the Intermediate one.
    step_bootstrap_fingerprint: 
    ###
    step_acme_cert_ca_provisioner: acme
    step_acme_cert_san: [] #sourced_from_a_hostvar
    step_acme_cert_contact: root@
    step_acme_cert_renewal_reload_services: "" # inventory variable.  

Conclusion

Sorry that this is quite brief. There is a lot of assumed ansible knowledge here and I think that I am probably showing that my knowledge in the area is not (yet?) vast.