Gunther Oracle APEX und Datenbank Wiki

Aufgabe

Regelmäßig (Jährlich) muss das Zertifikat der OEM Konsole des OEM 24ai ausgetauscht werden.

Damit das einfacher gehandelt werden kann, gehen wir das folgendermaßen an:

• Verzeichnis für die neue Wallet anlegen
• Neue Wallet anlegen
• Trust (Root + alle Intermediate unsere CA ) Zertifikate der Wallet hinzufügen
• Ein P12 Zertifikat aus dem Primary Key und den eigentlichen neuen Server Zertifikat erstellen
• User Zertifikat in die Wallet laden
• Pfad der Wallet in der OEM Consolen Komponente hinterlegen
• Neu starten

D.h. wir verwenden nicht das interne Zertifikats-Handling des OEM, sondern geben unsere eigene Wallet pro Jahr neu einfach an.

Die Pfade in meiner Umgebung sind ( Marketplace Image Oracle Cloud ):

Wer als WebLogic-Administrator zum ersten Mal das SSL-Zertifikat der OEM-Konsole erneuern soll, sucht meist erst an der falschen Stelle, beim Oracle HTTP Server (OHS).

Die OEM-Konsole (HTTPS-Zugang auf Port 7803/7301) läuft aber nicht über den OHS, sondern über einen eigenständigen Java-Prozess: den OEM API Gateway.

Im OEM-Stack laufen (vereinfacht) folgende Hauptprozesse:

Der OHS ist zwar im OEM-Middleware-Home installiert (das WebLogic-Domain-Template bringt ihn mit), wird aber im Standard-Betrieb nicht gestartet und nicht für die Konsole verwendet.

Im OEM-Deployment existiert tatsächlich eine OHS-Konfiguration mit Wallet-Einträgen (z.B. unter gc_inst/WebTierIH1/). Das verleitet WebLogic-Admins dazu, dort das Zertifikat einzutragen – diese Konfiguration hat jedoch keinen Effekt, solange der OHS-Prozess nicht aktiv ist.

Der API Gateway liest seinen Keystore-Pfad aus:

$OEM_INSTANCE/em/apigateway_inst/apigateway.properties

Schlüsselparameter:
EM_CONSOLE_KEYSTORE_PATH=/pfad/zur/cwallet.sso

Genau diese Datei wird im nachfolgenden Abschnitt angepasst.

Um zu sehen, welche Prozesse tatsächlich laufen und welcher den HTTPS-Port hält:

# Welcher Prozess hört auf Port 7803 (OEM Default Console Port)?
ss -tlnp | grep 7803
 
# API Gateway Prozess direkt suchen
ps -ef | grep apigateway | grep -v grep
 
# OHS läuft? (in der Regel: nein)
ps -ef | grep httpd | grep -v grep
 
# OMS Status gesamt
emctl status oms

ss zeigt für Port 7803 einen Java-Prozess (und keinen httpd), damit ist die Architektur wie erwartet: API Gateway aktiv, OHS nicht relevant.

Anforderungen:

• Alle Zertifikate der Kette müssen moderne Algorithmen wie SHA256 oder besser sein genügen
• Subject Alternative Name (SAN) muss mit den richtigen Aliase enthalten sein

Wichtig: Alle Zertifikate der Kette müssen moderne Algorithmen verwenden!

Bei der ersten Umstellung wurde festgestellt, dass das neue Zertifikat zwar im Firefox akzeptiert wurde, aber Chrome den Zugriff verweigerte.

Ursache: Chrome validiert die gesamte Zertifikatskette strikt — nicht nur das Server-Zertifikat, sondern auch alle Intermediate- und Root-Zertifikate. Firefox ist hier historisch toleranter.

Vor dem Import daher alle Zertifikate der Kette prüfen:

# Signaturalgorithmus prüfen - muss SHA256 oder besser sein, NICHT SHA1!
openssl x509 -in 05.Root_CA.txt       -noout -text | grep "Signature Algorithm"
openssl x509 -in 04.Intermediate2.txt -noout -text | grep "Signature Algorithm"
openssl x509 -in 03.Intermediate1.txt -noout -text | grep "Signature Algorithm"
openssl x509 -in 02.SSLCertificate.oem_srv_2026.txt -noout -text | grep "Signature Algorithm"
 
# Schlüssellänge prüfen - muss mindestens 2048 Bit sein
openssl x509 -in 05.Root_CA.txt       -noout -text | grep "Public-Key"
openssl x509 -in 04.Intermediate2.txt -noout -text | grep "Public-Key"
openssl x509 -in 03.Intermediate1.txt -noout -text | grep "Public-Key"

Erwartetes Ergebnis:

Signature Algorithm: sha256WithRSAEncryption   ← OK
Signature Algorithm: sha1WithRSAEncryption     ← NICHT akzeptiert von Chrome!

Chrome akzeptiert seit 2017 ausschließlich Zertifikate mit SAN-Eintrag! Der klassische Common Name (CN) allein wird von Chrome ignoriert. Fehlt der SAN-Eintrag komplett, zeigt Chrome sofort einen Zertifikatsfehler — unabhängig davon ob SHA-Algorithmus und Schlüssellänge korrekt sind. Firefox akzeptiert auch hier noch reine CN-Zertifikate.

SAN-Einträge im Server-Zertifikat prüfen:

# SAN-Einträge anzeigen
openssl x509 -in 02.SSLCertificate.oem_srv_2026.txt -noout -text \
  | grep -A1 "Subject Alternative Name"
 
# Alternativ kompakt:
openssl x509 -in 02.SSLCertificate.oem_srv_2026.txt -noout -ext subjectAltName

Erwartetes Ergebnis — alle DNS-Namen unter denen der OEM-Server erreichbar ist:

X509v3 Subject Alternative Name:
    DNS:gpisrvoem01.pipperr.local, DNS:gpisrvoem01, DNS:oem.pipperr.local

Folgende DNS-Namen müssen als SAN eingetragen sein:

• FQDN des OEM-Servers (z.B. gpisrvoem01.pipperr.local)
• Kurzname falls intern so aufgerufen (z.B. gpisrvoem01)
• Alias / Load Balancer Name falls vorhanden

Fehlt ein Name → Chrome zeigt Zertifikatsfehler sobald dieser Name in der URL verwendet wird. Korrektur nur möglich durch neues Zertifikat beim Aussteller (CA) — ein nachträgliches Hinzufügen von SAN-Einträgen ist nicht möglich.

Das Zertifikat wird extern mit einer CA erzeugt, das der SAN Eintrag im CSR nicht mit orapki erzeugt werden kann.

Mit openssl pkcs12 erstellen wir dann das Zertifikat für die Wallet mit dem, von der externe CA gelieferten, Server Zertifikat inkl. SANs.

#User ORACLE
 
# Ordner für das Bereitstellen der Zertifakte anlegen:
 
mkdir /home/oracle/zertifikate_2026
 
 
 
#zertifikat
01.srv_pk.txt  
02.SSLCertificate.oem_srv_2026.txt  
 
 
# Konsistenzprüfung: Passen Zertifikat und Private Key zusammen? (Modulus-Vergleich)
# Die MD5-Hashes beider Befehle müssen identisch sein!
openssl x509 -noout -modulus -in 02.SSLCertificate.oem_srv_2026.txt  | openssl md5
openssl rsa -noout -modulus -in 01.srv_pk.txt   | openssl md5
 
#Root Zertifkate
05.Root_CA.txt
04.Intermediate2.txt                
03.Intermediate1.txt    
 
#trust zert anzeigen
openssl x509 -in 05.Root_CA.txt        -text -noout
openssl x509 -in 04.Intermediate2.txt  -text -noout
openssl x509 -in 03.Intermediate1.txt  -text -noout

p12 File aus Key und Zertifikat anlegen

openssl pkcs12 -export -in 02.SSLCertificate.oem_srv_2026.txt  -inkey 01.srv_pk.txt  -out gpioem01.p12 -name "gpisrvoem01" -passout pass:<WALLET_PASSWORD>

Wallet neu anlegen mit -auto_login; Die cwallet.sso (auto-login) erlaubt den passwortlosen Zugriff durch OEM zur Laufzeit

mkdir /home/oracle/console_wallet_24ai_2026
$ORACLE_HOME/bin/orapki wallet create -wallet /home/oracle/console_wallet_24ai_2026  -auto_login

trust Importieren in Wallet

$ORACLE_HOME/bin/orapki wallet add -wallet /home/oracle/console_wallet_24ai_2026  -trusted_cert -cert 05.Root_CA.txt            -pwd <WALLET_PASSWORD>
$ORACLE_HOME/bin/orapki wallet add -wallet /home/oracle/console_wallet_24ai_2026  -trusted_cert -cert 04.Intermediate2.txt   -pwd <WALLET_PASSWORD>
$ORACLE_HOME/bin/orapki wallet add -wallet /home/oracle/console_wallet_24ai_2026  -trusted_cert -cert 03.Intermediate1.txt    -pwd <WALLET_PASSWORD>

User Zertifikat importieren:

$ORACLE_HOME/bin/orapki wallet import_pkcs12 -wallet /home/oracle/console_wallet_24ai_2026 -pwd <WALLET_PASSWORD> -pkcs12file gpioem01.p12 -pkcs12pwd <WALLET_PASSWORD>

Anzeigen lassen

$ORACLE_HOME/bin/orapki wallet display -wallet /home/oracle/console_wallet_24ai_2026

in der Datei apigateway.properties den Parameter EM_CONSOLE_KEYSTORE_PATH anpassen:

# Pfad zur Wallet im OEM anpassen
vi /u01/app/oracle/em/middleware_24ai/gc_inst/em/apigateway_inst/apigateway.properties
 
#Parameter umstellen:
EM_CONSOLE_KEYSTORE_PATH=/home/oracle/console_wallet_24ai_2026/cwallet.sso

emctl stop oms -all
emctl start oms

• Oracle Dokumentation - OEM 24ai Security Guide, Kapitel „Configuring Secure Communication“:
  • OEM 24ai Security Guide - Configuring Secure Communication

• Oracle MOS Note Doc ID 3046732.1 - „EM 24ai: How to Configure Enterprise Manager Console port with Custom/Third Party SSL Certificates“: unter MOS 3046732.1 (Support-Login erforderlich)