Hi, I am executing a deployment using -deploy-hook /etc/letsencrypt/renewal-hooks/deploy/auto_pfx.sh
Is there a variable that I can pass to this that will return only the primary value for the domain being created/renewed?
Currently I am using
#!/bin/bash
# Adjust these variables as necessary
# Where you want to final PKCS12 file to be stored.
CERT_PATH="/opt/app/certificate.pfx"
# Password to encrypt the PKCS12 file.
CERT_PW="ShoobyDooby"
# Path to LE files, RENEWED_LINEAGE provided by CertBot
PRIV_KEY_PEM="$RENEWED_LINEAGE/privkey.pem"
CERT_PEM="$RENEWED_LINEAGE/cert.pem"
CHAIN_PEM="$RENEWED_LINEAGE/chain.pem"
# If there's already a .pfx file, back it up
if [[ -f "$CERT_PATH" ]]; then
now=`date +%Y-%m-%d-%T`
mv $CERT_PATH $CERT_PATH.bak.$now
fi
# Le Conversion
openssl pkcs12 -export -out $CERT_PATH -inkey $PRIV_KEY_PEM -in $CERT_PEM -certfile $CHAIN_PEM -password pass:$CERT_PW
But I want the CERT_PATH="/opt/app/certificate.pfx" to be for the domain that is being renewed e.g. "mydomain.pfx" not "certificate.pfx"
Starting with Certbot 2.7.0, certbot provides the environment variables RENEWED_DOMAINS and FAILED_DOMAINS to all post renewal hooks. These variables contain a space separated list of domains. These variables can be used to determine if a renewal has succeeded or failed as part of your post renewal hook.
You may have to parse through it to get the name you need.
OR
If you call certbot renew with a specific --cert-name, then you can be sure about what the cert name will be.
Well, there really isn't a "primary", just a "first".
Per the deploy-hook docs, in addition to $RENEWED_LINEAGE (which may work well enough for naming files, no?), you can use $RENEWED_DOMAINS which "will contain a space-delimited list of renewed certificate domains". There's probably an easy way in bash to just take the first one. Maybe something like
Though there may be better ways and I haven't actually tried the above. It also may be that there's an easier client than certbot for installing into whichever system you have that needs a pfx file, rather than trying to cobble together a custom script, though sometimes keeping on using something you have already working is a good plan too.
Why does a Linux type system need a "pfx" type cert?
[which implies they are not going to be used in any Linux system]
[which would imply this is some sort of certificate manager (for Windows systems)]
[which begs the follow-up question: Why not allow the Windows systems to get their own certs?]
[which implies they can't - meaning they aren't directly accessible via HTTP from the Internet]
[which implies they are only internally accessible]
[which begs the "final" question: Why not use Windows AD to provide them the cert(s) they need?]
[which implies they don't have an AD]
OR
Maybe there's a Tomcat in the alley...
Thank you for the speedy reply.
Unfortunately, the central certificate store requires that certificates are named in a specific way which is my reasoning for wanting the first/primary domain as the sole filename.
If you're using IIS, you'll probably find it much easier to use a Windows-specific client like Certify the Web, win-acme, or Posh-ACME, than doing custom scripting to showhorn certbot into it. You certainly can keep using certbot, it's just that it doesn't have IIS integration in mind whereas other ACME clients do.
We have a hybrid environment, and it was decided that it would be easier to have the central certificate store running on a linux box which is already used for the allocation of ssl certificates to our linux servers.
