Jenkins HTTPS certificate expired

Build engineers cannot approve deployments because Chrome flags https://jenkins.company.com—jenkins ssl certificate expired on the Jetty listener or the Apache/nginx reverse proxy in front of it blocks the UI, not the agent JVM trust store used for git over SSH.

Classic Jenkins enables HTTPS either via --httpsPort + JKS/PKCS12 keystore in jenkins.xml / systemd override, or—more often—via nginx/Apache TLS while Jenkins stays HTTP on localhost. Incidents renew the edge cert but forget the keystore Jenkins itself uses in direct HTTPS setups.

Git webhooks from GitHub or GitLab POST to your Jenkins URL. Remote validators and inbound hook deliveries fail TLS verification when the leaf expired yesterday, silently starving pipelines.

First response

Determine TLS termination: curl -vI https://jenkins.example.com/login from outside, inspect response headers (Server: Jetty vs nginx). Locate keystore path in /etc/default/jenkins, systemd drop-in, or Helm ingress.tls.

echo | openssl s_client -connect jenkins.example.com:443 -servername jenkins.example.com 2>/dev/null | openssl x509 -noout -dates -subject

If Jetty serves directly:

keytool -list -v -keystore /path/to/jenkins.keystore -storepass SECRET 2>/dev/null | grep -E 'Alias|Until'

Redact passwords in tickets; use break-glass credentials only.

What this error means

Browsers and webhook senders validate HTTPS to the Jenkins public URL in Jenkins URL configuration. Expired notAfter fails before CSRF tokens or webhook JSON arrive. Agents calling jenkinsUrl over HTTPS for inbound agent protocols hit the same cert.

This is unrelated to agent–master encryption (JNLP4 with optional flags) unless agents use HTTPS transport to master. Most agents use TCP/JNLP on 50000 with separate trust.

Plugin callbacks (Sonar, Nexus) may call Jenkins HTTPS URLs—expired certs break quality gate reporting that looks like “Sonar down.”

Compliance and audit teams lose visibility when HTTPS UI breaks but agents keep running ephemeral jobs from queue backlog—false sense of partial availability delays executive communication.

Configuration as Code and Job DSL imports triggered from Git also depend on reachable HTTPS UI or API endpoints. Silent webhook failure stops promotion pipelines while cron jobs continue on old workspace state.

Blue Ocean and GitHub Branch Source plugins poll SCM over outbound TLS but receive inbound hooks on Jenkins URL—expired listener cert breaks the inbound leg even when outbound git clone from agents still works over SSH.

Common causes

Java keystore update imported only the leaf, missing intermediates—browsers succeed briefly then fail on trust (sometimes confused with expiry). Actually expired: annual corporate cert renewed on load balancer, Jenkins keystore on alternate URL never updated.

Kubernetes ingress secret rotated; Jenkins pod not restarted so old cert cached at old pods while Service already points to new ingress. jenkins.war migration copied old keystore from backup during DR drill.

Let’s Encrypt certbot renewed jenkins.example.com on host; Jenkins still references /etc/jenkins/jenkins.jks unchanged since install year.

Controller high availability setups with floating DNS may present renewed cert on passive controller while active controller still serves expired Jetty material until failover occurs—intermittent user reports confuse triage.

Apache mod_proxy to Jetty with SSLProxyVerify settings unrelated to front-end cert still matters for optional client cert setups; front-end expiry remains the dominant webhook failure mode.

Windows service installs that store keystore passwords in service XML sometimes prevent automated cert import scripts from running—manual keytool steps lag Linux nginx renewals by days.

Confirm from the outside

OpenSSL

curl -vI --connect-timeout 10 https://jenkins.example.com/login 2>&1 | grep -Ei 'expire|SSL certificate|Jetty'

Webhook perspective

curl -v -X POST https://jenkins.example.com/github-webhook/ -d '{}' 2>&1 | grep -Ei 'expire|SSL|403'

403 after clean TLS is good; SSL errors are not.

How to read the output

Note which hop answers: CDN, nginx, or Jetty. Match notAfter to the file or secret you control on that hop. apache reload after cert renew applies when Apache terminates.

Replay webhook delivery from Git provider UI after fix—HTTP 403 or 200 with Jenkins acknowledgment proves TLS path healthy; SSL errors in delivery log confirm lingering expiry on the hop the provider reaches.

Confirm Jenkins URL admin setting matches cert SAN

Mismatched hostname in Manage Jenkins → System causes users to bookmark the wrong name and report mixed error patterns while openssl on canonical name is clean.

Fix checklist

1. Confirm whether Jenkins or reverse proxy terminates TLS; document in CMDB.
2. Obtain renewed cert + chain for public Jenkins URL.
3. Reverse proxy path: update cert, reload nginx/Apache/HAProxy; Jenkins URL stays https://.
4. Jetty path: keytool -importkeystore or replace PKCS12; update JENKINS_HOME or systemd JENKINS_HTTPS_KEYSTORE; align httpsPort.
5. Restart Jenkins (or rolling restart controllers in HA) after keystore swap.
6. Test UI login, GitHub webhook delivery log, and one outbound plugin call.
7. Verify agent connection still uses intended port 50000/JNLP—not confused with HTTPS port.
8. Remove user bookmarks to “proceed anyway” instructions from wiki.

After proxy reload, validate crumb issuer and reverse proxy headers—mis-set X-Forwarded-Proto during cert maintenance sometimes surfaces as login loops mistaken for residual SSL issues.

Update any internal documentation that listed certificate fingerprints for plugin troubleshooting; outdated thumbprints waste secondary incidents.

For Kubernetes ingress, rollout Jenkins Deployment and any ingress controller shard that caches stale TLS secrets independently of cert-manager renewal events.

Notify SCM admins to redeliver failed hook batches once TLS is clean; queued SCM events do not always auto-retry on all Git hosting tiers.

When to use automation

Pipelines stall when jenkins ssl certificate expired breaks the UI—even if builds still run briefly from cron. Monitor the Jenkins URL configured in Manage Jenkins → System as live HTTPS.

/check that URL externally. If Jenkins is internal-only, probe from the same network webhooks use (SaaS hook senders need public valid certs). Pair monitoring with GitLab SSL for the full DevOps path.