Automated SSL certificate renewal for Oracle WebLogic Server

WebLogic won't load a renewed certificate on its own. CertKit will.

WebLogic serves its certificate from a custom identity keystore, a JKS file set by path, passphrase, and private key alias on each server. A renewed certificate does nothing until someone imports it into that keystore and restarts SSL on every server that reads it. Every 47 days.

CertKit issues and renews the certificate centrally, then the CertKit Agent writes the new keystore and restarts SSL through WLST. The JVMs keep running.

Start free trial Watch demo

Built for WebLogic

The pre-built WebLogic template ships in your CertKit account. No scripting required.

On every renewal, the agent writes the keystore to the path WebLogic already uses, with the same passphrase and alias. Then it connects to the admin server with WLST and runs restartSSLChannels() on each server you list. No server restart, no redeploy.

On a domain spread across machines, run an agent on each host. Each one writes its local keystore, and the SSL restart is safe to repeat.

How to import an SSL certificate into a WebLogic keystore

The manual process, if you want to do it yourself:

Create the key and request. Run keytool -genkeypair against the identity keystore, then keytool -certreq for the CSR. Or bring a key from elsewhere as a PKCS#12 file.
Import the signed certificate with its chain. Use keytool -importcert under the same alias as the private key, so the entry holds the full chain.
Point WebLogic at the keystore. Under Environment → Servers → your server → Configuration → Keystores, choose Custom Identity and Custom Trust or Custom Identity and Java Standard Trust. Set the path and passphrase, then the Private Key Alias and Private Key Passphrase on the SSL tab.
Load the new certificate. Restart the server, or run restartSSLChannels() from WLST.
Repeat on every machine. Each managed server reads its own local copy, so the keystore goes to every host in the domain.

Every one of these steps is manual, and WebLogic won't repeat any of them when the certificate renews. With lifetimes shrinking to 47 days, that's twelve times a year, on every server in the domain. Miss one managed server and the load balancer sends some users to an expired certificate.

At 47 days, automation is the only sustainable way to run WebLogic certificates. Here's how CertKit does it.

How it works

 Your WebLogic server      CertKit                 ACME CA
┌───────────────────┐     ┌──────────────────┐    ┌─────────────┐
│                   │     │                  │    │             │
│     ┌───────────────┐   │  Issue & Renew   │◄──►│             │
│     │ CertKit Agent │◄──┤   Certificates   │    │             │
│     └─────────┬─┬───┘   │                ┌───┐  └─────────────┘
│               │ │ │     └───────────┬────│DNS│
│ Keystore    ◄─┘ │ │                 │    └───┘
│ [x] Updated     │ │                 │
│                 │ │                 │
│ SSL listeners ◄─┘ │ ◄───────────────┘
│ [x] Restarted     │       Verify
└───────────────────┘

CertKit issues and renews certificates centrally using delegated DNS validation. You create a one-time CNAME record, and CertKit handles every ACME challenge after that.

The agent pulls each renewal over outbound HTTPS and works locally. WebLogic never runs ACME, and the admin credentials go to WLST through the process environment, never to disk.

Using CertKit to manage our public-facing SSL certificates has been an excellent decision. The platform is user-friendly, certificates are easy to deploy, and the automation agent streamlines the entire certificate lifecycle, eliminating concerns around shortening certificate validity periods.

Chris Austin, IT Engineer, Buckman

What CertKit handles

Issue and renew centrally. The one-time CNAME covers every renewal challenge.
Write the identity keystore. A JKS at the path, passphrase, and alias WebLogic already has. Trust keystores are not touched.
Restart SSL, not the server. WLST restarts the SSL listeners on each server you list, so applications keep running.
Cover multi-machine domains. An agent on each host writes its own keystore. Node Manager's keystore settings are left alone.
Verify and alert. CertKit checks that the new certificate is being served and alerts on keystore, WLST, or restart failures.
Audit every change. Every issuance, renewal, and deployment is logged. With certificate lifetimes heading to 47 days, that log is your compliance record.

Setup takes about ten minutes

Connect your domain. Add a one-time CNAME record to delegate DNS validation to CertKit.
Match the passphrases. CertKit uses one password for the keystore and the key inside it. If WebLogic's Private Key Passphrase differs from the keystore passphrase, change it once in the console.
Install the CertKit Agent. One command on each Windows host running WebLogic 12c or later.
Add the WebLogic deployment script. Enter the keystore path, passphrase, and alias, the Oracle home, a plain t3:// admin URL, admin credentials, and server names.

See the full architecture →

WebLogic deployment requirements and troubleshooting →

Why not just restart the server?

A full restart is the usual way to load a new keystore. In a production domain that means draining sessions and rolling through each managed server. WebLogic can restart only its SSL listeners, but that takes a WLST session against the admin server with credentials and exact server names.

CertKit's template does that on every renewal, so the certificate changes and the applications stay up.

WebLogic is just one part of your stack

Most environments have more than one place where TLS certificates live: Java servers like Tomcat, keystore-based servers like CrushFTP, integration platforms like Boomi, and systems of record like IBM i. CertKit automates all of it from one account.

See all integrations

Start automating WebLogic certificates today

Free 90-day trial. No credit card required. Direct access to our engineering team to get you set up.

Start free trial See pricing