WebLogic Server 14.1.2.0.0 on Oracle Linux 9

In the AWS Marketplace listing, choose Continue to Subscribe, then Continue to Configuration. Pick WebLogic Server 14.1.2.0.0 on Oracle Linux 9 as the software version, choose your Region, and choose Launch through EC2. Select m5.large (or larger for production application workloads), your key pair and a security group as above.

The root volume holds the WebLogic installation, your domain and its logs. Give it room for your applications (for example 30 GiB). The root file system grows to fill the volume on first boot.

To launch with the AWS CLI, replace the values in angle brackets:

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --block-device-mappings 'DeviceName=/dev/sda1,Ebs={VolumeSize=30,VolumeType=gp3}' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=weblogic}]'

Version SSH user

WebLogic Server 14.1.2.0.0 on Oracle Linux 9 ec2-user

ssh -i <your-key.pem> ec2-user@<public-ip>

Confirm the operating system release:

cat /etc/oracle-release

Oracle Linux Server release 9.8

On a newly launched instance, first boot creates the domain in about two and a half minutes. The instance is still loading its disk from the AMI snapshot, which makes the first Java start slow. The AdminServer then reaches RUNNING about 17 seconds later, so WebLogic is ready roughly three and a quarter minutes after launch. Two fresh 2 vCPU instances measured 3 min 16 s and 3 min 14 s from boot to RUNNING.

Until then, nginx is not started and port 443 refuses connections. Check the three units:

sudo systemctl is-active weblogic-firstboot.service weblogic.service nginx.service

active active active

weblogic-firstboot.service reports active because it is a one-time unit that has finished. On later boots it sees its marker and does nothing. The first-boot log shows the host name the instance was configured for and how long the domain took. This example comes from an instance whose disk was already warm:

sudo cat /var/log/weblogic-firstboot.log

[2026-10-20T14:44:42Z] weblogic-firstboot: configured host: ec2-54-208-37-17.compute-1.amazonaws.com [2026-10-20T14:44:42Z] weblogic-firstboot: creating base_domain (WLST offline from Oracle's wls.jar template) [2026-10-20T14:45:17Z] weblogic-firstboot: TLS certificate + nginx host for ec2-54-208-37-17.compute-1.amazonaws.com [2026-10-20T14:45:18Z] weblogic-firstboot: done in 36s; starting WebLogic and nginx

If weblogic.service shows activating, wait a few seconds and run the command again.

The values generated for this instance are in a root-only file. This command shows the file with the password hidden:

sudo sed -E 's/^(WEBLOGIC_PASSWORD=).*/\1<hidden>/' /root/weblogic-credentials.txt

# Oracle WebLogic Server 14.1.2.0.0 - this instance's own credentials (generated on its first boot) # Generated: 2026-10-20T14:45:18Z WEBLOGIC_USER=weblogic WEBLOGIC_PASSWORD=<hidden> WEBLOGIC_ADMIN_URL=https://ec2-54-208-37-17.compute-1.amazonaws.com/ WEBLOGIC_REST_URL=https://ec2-54-208-37-17.compute-1.amazonaws.com/management/weblogic/latest WEBLOGIC_WELCOME_URL=https://ec2-54-208-37-17.compute-1.amazonaws.com/console/welcome/ DOMAIN_HOME=/u01/app/oracle/product/user_projects/domains/base_domain TLS_CERT_SHA256_FINGERPRINT=82:3B:04:F3:0C:D0:20:0A:F6:DD:28:83:38:FF:D0:AC:A1:0E:74:07:2E:30:08:CA:53:FE:F5:C0:F1:9E:9D:5B

Print the password itself when you need it, and store it in your secret manager:

sudo sed -n 's/^WEBLOGIC_PASSWORD=//p' /root/weblogic-credentials.txt

The host name is the instance's public DNS name, or its public or private address when it has no public name. To serve WebLogic on your own DNS name, see Step 9.

The certificate is self-signed and generated on your instance. Check it, and compare its SHA-256 fingerprint with TLS_CERT_SHA256_FINGERPRINT above before you trust it in a browser or in Remote Console.

sudo openssl x509 -in /etc/nginx/ssl/weblogic.crt -noout -subject -enddate -ext subjectAltName

subject=CN=ec2-54-208-37-17.compute-1.amazonaws.com notAfter=Jan 22 14:46:58 2029 GMT X509v3 Subject Alternative Name: DNS:ec2-54-208-37-17.compute-1.amazonaws.com, IP Address:54.208.37.17, DNS:ip-172-31-94-136.ec2.internal, IP Address:172.31.94.136, DNS:localhost, IP Address:127.0.0.1

From the instance, the welcome page answers over HTTPS with that certificate, and port 80 redirects to HTTPS. Run:

H=$(sudo cat /etc/sac/weblogic-host)
curl -s -o /dev/null -w "%{http_code}\n" --cacert <(sudo cat /etc/nginx/ssl/weblogic.crt) --resolve "$H:443:127.0.0.1" "https://$H/console/welcome/"
curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" --resolve "$H:80:127.0.0.1" "http://$H/"

200 301 https://ec2-54-208-37-17.compute-1.amazonaws.com/

In your browser, open the WEBLOGIC_WELCOME_URL from Step 4. Accept the self-signed certificate after you check its fingerprint. WebLogic Server 14.1.2 serves this welcome page, which links to the WebLogic Remote Console download.

Install WebLogic Remote Console on your workstation from the welcome page link. Add an Admin Server Connection with:

• URL: the WEBLOGIC_ADMIN_URL from Step 4 (for example https://ec2-54-208-37-17.compute-1.amazonaws.com/)
• Username: weblogic
• Password: the password from Step 4

Remote Console talks to the AdminServer's REST management API over port 443. The certificate is self-signed, so either import /etc/nginx/ssl/weblogic.crt into Remote Console's trust store, or select Make Insecure Connection after you have compared the fingerprint. Remote Console covers deployments, data sources, JMS, security realms, users and groups, and monitoring.

The REST management API uses the same administrator credentials. This command reads the password from the credentials file and hands it to curl in a configuration stream, so it never appears on a command line:

H=$(sudo cat /etc/sac/weblogic-host)
PW=$(sudo sed -n 's/^WEBLOGIC_PASSWORD=//p' /root/weblogic-credentials.txt)
curl -s --cacert <(sudo cat /etc/nginx/ssl/weblogic.crt) --resolve "$H:443:127.0.0.1" -K <(printf 'user = "weblogic:%s"\n' "$PW") \
  "https://$H/management/weblogic/latest/serverRuntime?links=none&fields=name,state,weblogicVersion" unset PW

{ "weblogicVersion": "WebLogic Server 14.1.2.0.0 Tue Nov 26 02:40:45 GMT 2024 2171472", "state": "RUNNING", "name": "AdminServer" }

The domain itself:

H=$(sudo cat /etc/sac/weblogic-host)
PW=$(sudo sed -n 's/^WEBLOGIC_PASSWORD=//p' /root/weblogic-credentials.txt)
curl -s --cacert <(sudo cat /etc/nginx/ssl/weblogic.crt) --resolve "$H:443:127.0.0.1" -K <(printf 'user = "weblogic:%s"\n' "$PW") \
  "https://$H/management/weblogic/latest/domainConfig?links=none&fields=name,domainVersion,productionModeEnabled" unset PW

{ "productionModeEnabled": true, "domainVersion": "14.1.2.0.0", "name": "base_domain" }

The same request from a browser signed in as weblogic:

A request without credentials is refused with 401. The instance also carries a self-test that proves the password, the anonymous refusal and a wrong-password refusal in one run:

H=$(sudo cat /etc/sac/weblogic-host)
curl -s -o /dev/null -w "%{http_code}\n" --cacert <(sudo cat /etc/nginx/ssl/weblogic.crt) --resolve "$H:443:127.0.0.1" "https://$H/management/weblogic/latest/serverRuntime"
sudo /usr/local/sbin/weblogic-selftest

401 per-instance admin password: AdminServer RUNNING over https://ec2-54-208-37-17.compute-1.amazonaws.com/ (instance certificate verified); anonymous HTTP 401; wrong password HTTP 401 WLS_ROUNDTRIP_OK

State-changing REST requests also need the X-Requested-By header, which is WebLogic's own protection against cross-site requests.

The WebLogic Scripting Tool (WLST) runs as the oracle user and connects to the AdminServer over T3 on the loopback address. This example hands the password to WLST in a file readable only by oracle, never on a command line or in an environment variable. It prints the domain and server state, then removes the file:

PWF=$(sudo mktemp /run/wlst-pw.XXXXXX)
sudo sed -n 's/^WEBLOGIC_PASSWORD=//p' /root/weblogic-credentials.txt | sudo tee "$PWF" >/dev/null
sudo chown oracle:oinstall "$PWF" cat > /tmp/wlst-check.py <<'PY' import os f = open(os.environ['PWF']); pw = f.read().strip(); f.close() connect('weblogic', pw, 't3://127.0.0.1:7001') print('Connected to domain: ' + cmo.getName()) serverRuntime() print('AdminServer state: ' + cmo.getState()) disconnect() PY chmod 0644 /tmp/wlst-check.py
sudo setpriv --reuid=oracle --regid=oinstall --init-groups env HOME=/home/oracle PWF="$PWF" \
  /u01/app/oracle/product/oracle_common/common/bin/wlst.sh /tmp/wlst-check.py 2>&1 | grep -E 'Connected to domain|AdminServer state'
sudo rm -f "$PWF" /tmp/wlst-check.py

Connected to domain: base_domain AdminServer state: RUNNING

For an interactive session, run sudo -u oracle /u01/app/oracle/product/oracle_common/common/bin/wlst.sh, then connect('weblogic', '<password>', 't3://127.0.0.1:7001'), edit(), startEdit(), your changes, save() and activate().

Point your DNS name at the instance, then run the following command, replacing the example name:

sudo weblogic-set-host weblogic.example.com

The command generates a new self-signed certificate for the name, adds it to nginx, and sets it as WebLogic's front-end host. It also updates the URLs in /root/weblogic-credentials.txt and restarts the AdminServer, which takes about a minute.

To use a certificate from your own certificate authority instead, run the command first. Then replace /etc/nginx/ssl/weblogic.crt and /etc/nginx/ssl/weblogic.key (key owned by root:nginx, mode 0640) and run sudo systemctl reload nginx.

To replace the generated password with one of your own, first reset it online with WLST, as in Step 8, reading the current password from a file. Then write the new password into boot.properties so the AdminServer can still start unattended. WebLogic encrypts the file on its next start. Finally, update the credentials file and restart the service:

sudo -u oracle /u01/app/oracle/product/oracle_common/common/bin/wlst.sh connect('weblogic', '<current-password>', 't3://127.0.0.1:7001') cd('/SecurityConfiguration/base_domain/Realms/myrealm/AuthenticationProviders/DefaultAuthenticator') cmo.resetUserPassword('weblogic', '<new-password>') disconnect() exit()
sudo -u oracle sh -c 'umask 077; cat > /u01/app/oracle/product/user_projects/domains/base_domain/servers/AdminServer/security/boot.properties' username=weblogic password=<new-password> (press Ctrl-D)
sudo sed -i 's/^WEBLOGIC_PASSWORD=.*/WEBLOGIC_PASSWORD=<new-password>/' /root/weblogic-credentials.txt
sudo systemctl restart weblogic.service

Typing the password into the interactive WLST prompt and cat keeps it out of other users' command-line history. WebLogic locks an account for 30 minutes after five wrong passwords in a row.

This image is built from Oracle's WebLogic Server 14.1.2.0.0 base release with no Patch Set Update (PSU) or other Oracle patch applied. Oracle distributes WebLogic patches through My Oracle Support to licensed customers.

Apply the current WebLogic PSU and security patches with your own Oracle support entitlement. Follow Oracle's patching documentation for Oracle Fusion Middleware 14.1.2 (Patching with OPatch) and the quarterly Oracle Critical Patch Update advisories. Stop the AdminServer first (sudo systemctl stop weblogic.service), apply the patch as the oracle user, then start the AdminServer again.

Java updates come from Oracle Linux. WebLogic runs on Oracle Linux's OpenJDK 21 through the alternatives path /usr/lib/jvm/jre-21-openjdk, which points at the installed java-21-openjdk-headless package. dnf-automatic installs its security updates with the other Oracle Linux errata every day. You can also update by hand with sudo dnf -y update java-21-openjdk-headless.

Nothing in WebLogic names the versioned JDK directory, so no WebLogic file changes. Restart the AdminServer so it runs on the new JDK:

sudo systemctl restart weblogic.service

Oracle Linux packages, including nginx, are updated the same way: dnf-automatic daily, or sudo dnf -y update.

Check the installed versions and the JDK the running AdminServer uses:

sudo setpriv --reuid=oracle --regid=oinstall --init-groups /usr/lib/jvm/jre-21-openjdk/bin/java -cp /u01/app/oracle/product/wlserver/server/lib/weblogic.jar weblogic.version | grep 'WebLogic Server' rpm -q java-21-openjdk-headless readlink -f /usr/lib/jvm/jre-21-openjdk
sudo /usr/local/sbin/weblogic-selftest | grep 'AdminServer JVM'

WebLogic Server 14.1.2.0.0 Tue Nov 26 02:40:45 GMT 2024 2171472 java-21-openjdk-headless-21.0.12.1.1-1.2.0.1.el9.x86_64 /usr/lib/jvm/java-21-openjdk-21.0.12.1.1-1.2.0.1.el9.x86_64 AdminServer JVM: java.home=/usr/lib/jvm/java-21-openjdk-21.0.12.1.1-1.2.0.1.el9.x86_64 (java-21-openjdk-headless-21.0.12.1.1-1.2.0.1.el9.x86_64) java.vendor=Red Hat, Inc. java.vm.name=OpenJDK 64-Bit Server VM java.runtime.version=21.0.12.1+1-LTS; JAVA_HOME=/usr/lib/jvm/jre-21-openjdk (alternatives)

The version numbers move on as Oracle Linux publishes OpenJDK updates. The java.vendor property reads "Red Hat, Inc." because Oracle Linux rebuilds the same OpenJDK sources. The package itself is Oracle Linux's, with vendor Oracle America.

Run WebLogic on Oracle JDK instead (Oracle support customers). Oracle's WebLogic Server 14.1.2 certification names Oracle JDK 17 and 21. If your Oracle support contract requires a certified JDK, install Oracle JDK yourself under your own Oracle entitlement. SecureAnyCloud does not supply it.

• Sign in to Oracle with your account and download the Oracle JDK 21 RPM for Linux x64 (jdk-21_linux-x64_bin.rpm) under the terms your Oracle license gives you. Then copy it to the instance.
• Install it and find its directory:

bash sudo dnf -y install ./jdk-21_linux-x64_bin.rpm ORACLE_JDK=$(dirname "$(dirname "$(rpm -ql jdk-21 | grep '/bin/java$' | head -1)")"); echo "${ORACLE_JDK}"

• Point every place WebLogic reads JAVA_HOME at it (the systemd unit, the Oracle home, the domain scripts, the oracle user's profile and the SecureAnyCloud tools), then restart:

bash sudo grep -rlF /usr/lib/jvm/jre-21-openjdk /etc/systemd/system/weblogic.service /u01/app/oracle/product/oui \ /u01/app/oracle/product/user_projects/domains/base_domain/bin /home/oracle/.bash_profile \ /usr/local/lib/sac/weblogic/common.sh | sudo xargs sed -i "s|/usr/lib/jvm/jre-21-openjdk|${ORACLE_JDK}|g" sudo systemctl daemon-reload sudo systemctl restart weblogic.service sudo /usr/local/sbin/weblogic-selftest | tail -2

weblogic-selftest first proves the login path as usual. It then stops at its last check with a FAIL: AdminServer JVM ... line, because that check expects Oracle Linux's OpenJDK. The line shows the java.home and VM name of the Oracle JDK that the AdminServer now runs on.

From then on, you update Oracle JDK under your Oracle entitlement. To go back, run the same sed with the two paths swapped.

Only SSH, HTTP and HTTPS listen on the network. The AdminServer listens on the loopback address only:

sudo ss -tlnH | awk '{print $4}' | sort -u

0.0.0.0:22 0.0.0.0:443 0.0.0.0:80 [::]:22 [::]:443 [::]:80 [::ffff:127.0.0.1]:7001

SSH accepts key logins only. Password and keyboard-interactive logins, root logins and X11 forwarding are off. The settings live in /etc/ssh/sshd_config.d/00-sac.conf, which sshd reads before any other file (sshd keeps the first value it reads). The sshd -T command shows the values sshd actually uses:

sudo sshd -T | grep -E '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin|x11forwarding|pubkeyauthentication) '

permitrootlogin no pubkeyauthentication yes passwordauthentication no kbdinteractiveauthentication no x11forwarding no

A request for a host name the instance does not serve gets no answer (000 in curl):

curl -sk -o /dev/null -w "%{http_code}\n" -H "Host: attacker.example" https://127.0.0.1/ || echo "no answer, as intended"

000 no answer, as intended

Every process of the WebLogic and nginx services is blocked from the instance metadata service. This covers the AdminServer, every application you deploy, and the nginx master and workers. The rest of the instance can still use the metadata service, and first boot uses it to find the host name.

On Oracle Linux 9, systemd enforces this. Both units carry IPAddressDeny= for the metadata addresses, which the kernel applies to everything in the unit's control group, whatever user it runs as:

sudo systemctl show -p IPAddressDeny weblogic.service nginx.service

IPAddressDeny=169.254.169.254/32 fd00:ec2::254/128 168.63.129.16/32 IPAddressDeny=169.254.169.254/32 fd00:ec2::254/128 168.63.129.16/32

To see it, send a request from inside each service's control group and one from your own session. A result of 000 means no answer:

for u in weblogic nginx; do
CG=$(systemctl show -p ControlGroup --value $u.service)
sudo bash -c "echo \$\$ > /sys/fs/cgroup$CG/cgroup.procs && exec curl -s -m 5 -o /dev/null -w 'inside $u.service: %{http_code}\n' -X PUT -H 'X-aws-ec2-metadata-token-ttl-seconds: 60' http://169.254.169.254/latest/api/token" done
sudo curl -s -m 5 -o /dev/null -w "outside the units: %{http_code}\n" -X PUT -H "X-aws-ec2-metadata-token-ttl-seconds: 60" http://169.254.169.254/latest/api/token

inside weblogic.service: 000 inside nginx.service: 000 outside the units: 200

If an application you deploy needs AWS credentials, give it its own credentials (for example AWS Secrets Manager or environment-specific access keys) rather than the instance role. Alternatively, override the setting deliberately with sudo systemctl edit weblogic.service, where an empty IPAddressDeny= line clears it.

SELinux is enforcing:

getenforce

Enforcing

Remote Console shows WebLogic's own security check as a banner ("Security warnings detected"), and the REST API also exposes it. On this image, the domain is created with WebLogic's default internal servlets disabled (DefaultInternalServletsDisabled, which turns off T3/IIOP tunnelling over HTTP and clears warning 091031). nginx answers 404 for WebLogic's internal paths (/bea_wls_internal/, /bea_wls_deployment_internal/, /_async/, /wls-wsat/ and others).

The report is computed on demand, so refresh it first, then read it:

H=$(sudo cat /etc/sac/weblogic-host)
PW=$(sudo sed -n 's/^WEBLOGIC_PASSWORD=//p' /root/weblogic-credentials.txt)
curl -s -o /dev/null -w "refresh: %{http_code}\n" --cacert <(sudo cat /etc/nginx/ssl/weblogic.crt) --resolve "$H:443:127.0.0.1" -K <(printf 'user = "weblogic:%s"\n' "$PW") \
  -H "X-Requested-By: sac" -H "Content-Type: application/json" -d '{}' -X POST \
  "https://$H/management/weblogic/latest/domainRuntime/domainSecurityRuntime/refreshCache"
curl -s --cacert <(sudo cat /etc/nginx/ssl/weblogic.crt) --resolve "$H:443:127.0.0.1" -K <(printf 'user = "weblogic:%s"\n' "$PW") \
  "https://$H/management/weblogic/latest/domainRuntime/domainSecurityRuntime?links=none&fields=securityValidationWarnings" | grep -E '"id"' unset PW

refresh: 200 "id": "091033" "id": "091032"

Two items remain, and both follow from the design:

• 091033, no dedicated HTTPS network channel. nginx terminates HTTPS on port 443, and the AdminServer listens on 127.0.0.1:7001 only. No WebLogic network channel is reachable from the network at all.
• 091032, demo identity and trust keystores. The AdminServer has no SSL listener of its own, so these keystores are not used to serve traffic. WebLogic 14.1.2 generates them, with its own demo certificate authority and the rest of the domain, on your instance's first boot. They are unique to your instance rather than a shared demo key. If you enable SSL on a WebLogic network channel, configure your own identity and trust keystores first (KeyStores = CustomIdentityAndJavaStandardTrust or CustomIdentityAndCustomTrust). That also clears this item.