Quick command to get the base-64 encoded certificate — useful for establishing trust with AD DS domain controllers
openssl s_client -connect dc5.example.com:636 -showcerts </dev/null 2>/dev/null | awk ‘BEGIN{c=0} /BEGIN CERTIFICATE/{c++} c==1{print} /END CERTIFICATE/ && c==1{exit}’
After completing an in-place upgrade from Fedora 43 to Fedora 44, dnf5 failed to run with this error:
[lisa@fedora05 ~]# dnf5 update
Cannot load dnf5 plugin: /usr/lib64/dnf5/plugins/automatic_cmd_plugin.so
Cannot load shared library “/usr/lib64/dnf5/plugins/automatic_cmd_plugin.so”: libdnf5-cli.so.2: cannot open shared object file: No such file or directory
The Fedora 44 upgrade completed, and the installed dnf5 packages were all current Fedora 44 versions. However, there was a leftover plugin file still sitting in /usr/lib64/dnf5/plugins/automatic_cmd_plugin.so.
That file was not owned by any RPM package and had been built against an older library, libdnf5-cli.so.2.
But Fedora 44 had /usr/lib64/libdnf5-cli.so.3.
dnf5 was trying to load a stale plugin from before the upgrade.
These commands showed the problem:
ls -l /usr/lib64/libdnf5-cli.so*
rpm -qf /usr/lib64/dnf5/plugins/automatic_cmd_plugin.so
ldd /usr/lib64/dnf5/plugins/automatic_cmd_plugin.so
Results:
libdnf5-cli.so.3 existedautomatic_cmd_plugin.so was not owned by any packageldd showed it was looking for libdnf5-cli.so.2Remove the orphaned plugin file:
rm /usr/lib64/dnf5/plugins/automatic_cmd_plugin.so
ldconfig
dnf5 update
After deleting the stale plugin, dnf5 worked normally again.
This appears to be a leftover orphaned dnf5 plugin from before the major version upgrade. Even though the main dnf5 and libdnf5 packages were updated correctly, dnf5 still tried to load the old .so file it found in the plugins directory.
Looking at network slowness, I noticed a lot of overrun errors and an inexplicable amount of broadcast traffic. Running a sniffer trace … these tuya bulbs announce themselves in a constant loop. We’ll add a network filter for now, but some other firmware on these bulbs would be great!
As I work through automating certificate installation, most applications have a “service account” user that has write access to the SSL certificate files. However, that user does not generally have permission to restart the application service.
We could get the ID added to sudoers with specific rights to manage the service … but it seemed more straightforward to use Polkit for very granular control permitting the service account to run specific verbs with systemctl.
The following rule allows the “tomcatadmin” user to run systemctl start, stop, or restart with the apache-tomcat.service unit.
cat > /etc/polkit-1/rules.d/60-apache-tomcat-tomcatadmin.rules <<'EOF'
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.systemd1.manage-units") {
var unit = action.lookup("unit");
var verb = action.lookup("verb");
if (subject.user == "tomcatadmin" &&
unit == "apache-tomcat.service" &&
(verb == "start" || verb == "stop" || verb == "restart")) {
return polkit.Result.YES;
}
}
});
EOF
With recent Windows updates, users now get a big message saying “Caution: Unknown remote connection” when launching RDP sessions from our CyberArk server. Easy enough – I have an internal CA, I can generate a code signing certificate, so I can sign these RDP files.
Except, in testing, I continually got an error indicating rdpsign cannot find the certificate. It’s there. I have a private key. It’s a code signing certificate. An hour or so later, I realize the “sha256” value is actually the SHA-1 thumbprint. Which … not my first guess and really more of a “out of reasonable options, start trying silly things” guess.
“$env:SystemRoot\System32\rdpsign.exe” /v /sha256 $hash256 $rdp
Voila, “All rdp file(s) have been successfully signed.”
Sigh — and, after all this work? I go from the red “unknown publisher” error to a yellow “yeah, you should think about this” banner.
A quick PowerShell script to report on its own signature data:
$scriptPath = $PSCommandPath
if (-not $scriptPath) {
throw 'This script must be run from a .ps1 file so $PSCommandPath is available.'
}
$sig = Get-AuthenticodeSignature -FilePath $scriptPath
Write-Host "Script path: $scriptPath`n" -ForegroundColor Cyan
[PSCustomObject]@{
Status = $sig.Status
StatusMessage = $sig.StatusMessage
SignatureType = $sig.SignatureType
IsOSBinary = $sig.IsOSBinary
SignerSubject = $sig.SignerCertificate.Subject
SignerThumbprint = $sig.SignerCertificate.Thumbprint
SignerNotBefore = $sig.SignerCertificate.NotBefore
SignerNotAfter = $sig.SignerCertificate.NotAfter
TimeStamperSubject = $sig.TimeStamperCertificate.Subject
TimeStamperThumbprint = $sig.TimeStamperCertificate.Thumbprint
} | Format-List
To sign the script:
$thumb = '87E4C1F40D1DB8486F1E9093A76626AB1DFDEA30'
$scriptPath = "$env:USERPROFILE\git\CyberSecurity\misc\CheckPSSignature.ps1"
$cert = Get-ChildItem Cert:\CurrentUser\My, Cert:\LocalMachine\My |
Where-Object {
$_.Thumbprint -eq $thumb -and
$_.HasPrivateKey -and
($_.EnhancedKeyUsageList | Where-Object {
$_.ObjectId -eq '1.3.6.1.5.5.7.3.3' -or $_.FriendlyName -eq 'Code Signing'
})
} |
Select-Object -First 1
if (-not $cert) {
throw "Code signing certificate $thumb not found."
}
Set-AuthenticodeSignature -FilePath $scriptPath -Certificate $cert
Get-AuthenticodeSignature -FilePath $scriptPath | Format-List *
And now the script is signed:
This document assumes:
Azure CLI is installed (https://learn.microsoft.com/en-us/cli/azure/install-azure-cli-linux)
You already have an agent pool with online agent in a deployment pool
And, finally, that you have a pipeline deployment that uses a static keystore. We will be replacing that static keystore file with one obtained from the Azure Key Vault.
First, ensure the Azure DevOps service connection used by the pipeline has access to LJRVenafiTestKeyVault with at least:
From the Azure command line, e.g.
az role assignment create –assignee-object-id 107d2d9a-4d1b-4d8b-9cd6-0f95587eb9ae –assignee-principal-type ServicePrincipal –role “Key Vault Secrets User” –scope “/subscriptions/dede429d-a340-4e90-8f76-05aa5280a1f5/resourceGroups/ljr-keyvault-demo/providers/Microsoft.KeyVault/vaults/LJRVenafiTestKeyVault”
If you do not know which service connection is being used, update and run the pipeline. It will fail with a permission error, but the service connection’s usage history will reflect the release pipeline’s use:
Update your pipeline to retrieve the certificate from the Azure KeyVault. Add an Azure CLI task using an inline script
set -euo pipefail
PFX_FILE=”$AGENT_TEMPDIRECTORY/VenafiDeployedCertificate.pfx”
az keyvault secret download \
–vault-name LJRVenafiTestKeyVault \
–name VenafiDeployedCertificate \
–file “$PFX_FILE” \
–encoding base64
echo “Downloaded PFX to $PFX_FILE”
echo “##vso[task.setvariable variable=PFX_PATH]$PFX_FILE”
If you need a JKS file, add an additional bash task with an inline script
set -euo pipefail
JKS_FILE=”$AGENT_TEMPDIRECTORY/VenafiDeployedCertificate.jks”
# Verify keytool exists
command -v keytool >/dev/null 2>&1 || { echo “keytool not found on agent”; exit 1; }
keytool -importkeystore \
-srckeystore “$(PFX_PATH)” \
-srcstoretype PKCS12 \
-srcstorepass “” \
-destkeystore “$JKS_FILE” \
-deststoretype JKS \
-deststorepass “$(JksPassword)” \
-destkeypass “$(JksPassword)” \
-noprompt
echo “Created JKS at $JKS_FILE”
echo “##vso[task.setvariable variable=JKS_PATH]$JKS_FILE”
Add a pipeline variable for the JKS Password – make sure to click the lock icon to protect the password
And, finally, add a bash task task to copy the JKS or PFX file to the proper place on the server
set -euo pipefail
# Copy JKS to location on server used in app config
TARGET_DIR=”/opt/credential-injection/certs”
TARGET_JKS=”$TARGET_DIR/VenafiDeployedCertificate.jks”
cp “$(JKS_PATH)” “$TARGET_JKS”
chmod 600 “$TARGET_JKS”
echo “JKS copied to $TARGET_JKS”
# Or copy pfx to location on server used in app config
TARGET_PFX=”$TARGET_DIR/VenafiDeployedCertificate.pfx”
cp “$(PFX_PATH)” “$TARGET_PFX”
chmod 600 “$TARGET_PFX”
Create a release to run the pipeline. Looking at the logs, you should see a confirmation that the pfx file was created
And, if you are creating a JKS file, a confirmation that it was created as well
You should also see the certificate file(s) on the server:
For many Java-based applications, Java KeyStore (JKS) has been the default for years. It’s familiar, widely used, and still supported. But “still supported” is not the same as “still the best choice.” If your application or platform supports it, now is a good time to move away from JKS and standardize on PKCS#12.
JKS is Java-specific and tied to older Java conventions. By contrast, PKCS#12 is a standards-based format supported across platforms, tools, and vendors.
That difference matters operationally. Certificate and key material increasingly needs to work across Java applications, web servers, load balancers, cloud services, and automation tooling. PKCS#12 is far better suited to that multi-platform reality.
JKS should not be considered a modern format for protecting private keys.
It uses non-standard, legacy protection mechanisms and has historically relied on weaker constructions than modern PKCS#12 implementations. As with any password-protected container, security depends heavily on password strength—but JKS offers less margin for error compared to more modern formats.
This becomes especially relevant if a keystore file is exposed. Offline password cracking is a realistic risk, and widely available tools can target JKS files—particularly when organizations use weak or reused passwords.
This does not mean existing JKS files are inherently compromised. It does mean JKS should no longer be the default when stronger, more widely supported alternatives exist.
The Java platform has already made this transition. Starting with Java 9, PKCS#12 became the default keystore type. JKS remains supported, but PKCS#12 is now the preferred standard in modern Java environments.
In many environments, JKS persists simply because it’s what teams have always used—not because it’s required. Most modern Java frameworks, application servers, and tools support PKCS#12. For example, Tomcat has supported PKCS#12 since version 5.0, and current Java tooling handles it natively.
In practice, many applications can switch with little to no functional impact.
PKCS#12 offers several clear advantages:
If you manage Java applications or infrastructure, this is a good opportunity to review current keystore usage.
For many use cases, converting is straightforward. For example:
keytool -importkeystore \
-srckeystore keystore.jks \
-destkeystore keystore.p12 \
-deststoretype PKCS12
Before making changes, confirm support with the relevant application or platform vendor.
Key questions:
In most cases, the answer will be yes—but it’s still worth validating before making production changes.
JKS is not deprecated, but it is no longer the format organizations should be choosing by default.
It is a legacy, Java-specific keystore format with limited interoperability and older security characteristics. Meanwhile, PKCS#12 is standards-based, broadly supported, and the default in modern Java. If your application supports PKCS#12, prefer it. If you’re unsure, check—because in many cases, you can make the switch with minimal effort.
Choosing a modern keystore format is a small change that can meaningfully improve both security posture and operational flexibility.
While Venafi documentation for each individual installation driver includes the port requirements, there was no single table view of the installation options and what port(s) are needed for that installation driver to work. Ended up putting together a table for our firewall rule discussion.
| Installation Type | Description | Default Port | Notes |
| Adaptable Installation Driver | Powershell | 22, 5985, 5986 | This is running a custom script |
| Amazon Web Services | 443 | To internet destination | |
| Apache HTTP | Uses ssh | 22 | |
| Azure Key Vault | 443 | To internet destination | |
| Citrix NetScaler | NITRO API | 443 | |
| F5 BigIP | iControl REST API | 443 | |
| Google Cloud Load Balancer | 443 | To internet destination | |
| IBM DataPower | DataPower Gateway | 5550, 5554 | |
| IBM Keystore | |||
| JKS | Uses ssh | 22 | Tomcat, Jboss, WebLogic |
| Oracle iPlanet Web Server | Uses ssh | 22 | |
| PEM | Uses ssh | 22 | |
| PKCS#12 | Uses ssh | 22 | |
| Windows CAPI & IIS | Uses WinRM | 5985, 5986 | |
In case anyone else ever needs to set a windows dynamic port range for magic RPC “stuff” — there’s a minimum range size of 255. If you make the range to small, you get an incredibly vague and not-useful “the parameter is incorrect” error. Increase num to at least the min value, and you don’t be going in circles trying to figure out what in your command doesn’t match the parameters in the documentation!
