Operations | Monitoring | ITSM | DevOps | Cloud

The old deployment flow expected a lot from you. You had to know what format your certificate needed to be in. You had to know where it should be stored on the target system. Then you had to review and customize a deployment script in a code editor before anything ran. It turns out most of you don’t want to do that. And fair enough, staring at a script editor when you just want a certificate on your Exchange server is a little intimidating.

Every certificate renewal automation tool has to answer one architecture question before it does anything else: where does the private key get generated? A reader who used to be “the certificate guy” at his organization emailed me this week to ask about exactly that: It’s the right instinct. It’s also how most automation tools work. Certbot generates the key on the server, builds a certificate signing request, and the private key never leaves the machine.

How do we keep our Sonicwall certificates up to date as certificate lifetimes get shorter? We’re already at 200 day certs with 100 then 47 day certificates coming soon. A certificate you used to touch once every year now needs replacing up to twelve times a year. Doing this by hand is out of the question, no one has the time. Even if they did, the frequent updates is just asking for mistakes. Luckily, this can be automated using the SonicOS API.