WebLogic Server 15.1.1.0.0 on Oracle Linux 9

In the AWS Marketplace listing, choose Continue to Subscribe, then Continue to Configuration. Pick WebLogic Server 15.1.1.0.0 on Oracle Linux 9 as the software version, pick your Region, and choose Launch through EC2.

Choose m5.large (or larger for production application workloads), your key pair, and a security group as described above. The root volume holds the WebLogic installation, your domain and its logs, so 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}]'

Connect over SSH as the default user for your version:

• WebLogic Server 15.1.1.0.0 on Oracle Linux 9: SSH user 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 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 about three minutes after launch. This was measured on nine fresh 2 vCPU, 8 GiB instances, which took 2 min 26 s to 3 min 43 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 a newly launched instance. On a warm disk, the domain takes about 40 seconds:

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

[2026-10-20T22:55:12Z] weblogic-firstboot: configured host: ec2-35-175-233-6.compute-1.amazonaws.com [2026-10-20T22:55:12Z] weblogic-firstboot: creating base_domain (WLST offline from Oracle's wls.jar template) [2026-10-20T22:57:16Z] weblogic-firstboot: TLS certificate + nginx host for ec2-35-175-233-6.compute-1.amazonaws.com [2026-10-20T22:57:17Z] weblogic-firstboot: done in 125s; 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 15.1.1.0.0 - this instance's own credentials (generated on its first boot) # Generated: 2026-10-20T22:57:17Z WEBLOGIC_USER=weblogic WEBLOGIC_PASSWORD=<hidden> WEBLOGIC_ADMIN_URL=https://ec2-35-175-233-6.compute-1.amazonaws.com/ WEBLOGIC_REST_URL=https://ec2-35-175-233-6.compute-1.amazonaws.com/management/weblogic/latest WEBLOGIC_WELCOME_URL=https://ec2-35-175-233-6.compute-1.amazonaws.com/console/welcome/ DOMAIN_HOME=/u01/app/oracle/product/user_projects/domains/base_domain TLS_CERT_SHA256_FINGERPRINT=BC:CB:32:30:71:0E:5B:21:A7:B9:7A:7E:CF:58:E8:3D:70:3A:B6:CA:E6:AD:66:6A:98:6C:D1:D9:A4:10:82:68

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. When the instance has no public name, it is the instance's public or private address. To serve WebLogic on your own DNS name, see Step 9.

The certificate is self-signed and generated on your instance. Check the certificate, 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-35-175-233-6.compute-1.amazonaws.com notAfter=Jan 22 22:57:17 2029 GMT X509v3 Subject Alternative Name: DNS:ec2-35-175-233-6.compute-1.amazonaws.com, IP Address:35.175.233.6, DNS:ip-172-31-95-72.ec2.internal, IP Address:172.31.95.72, 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:

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-35-175-233-6.compute-1.amazonaws.com/

Only root and nginx can read the certificate file, so these commands hand it to curl with sudo cat. The file is a public certificate, not a secret.

In your browser, open the WEBLOGIC_WELCOME_URL from Step 4, and accept the self-signed certificate after checking its fingerprint. WebLogic Server 15.1.1 serves this welcome page because the original Administration Console is no longer part of WebLogic Server. The page links to the WebLogic Remote Console download and mentions the Hosted WebLogic Remote Console (see Step 6).

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

• URL: the WEBLOGIC_ADMIN_URL from Step 4 (for example https://ec2-35-175-233-6.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. Because the certificate is self-signed, either import /etc/nginx/ssl/weblogic.crt into Remote Console's trust store, or compare the fingerprint and then tick Make Insecure Connection. Remote Console covers deployments, data sources, JMS, security realms, users and groups, and monitoring.

Hosted Remote Console in your browser (optional). WebLogic Server 15.1.1 also ships the Remote Console as a web application (wlserver/server/lib/wls-remote-console.war, Remote Console 2.4.18). You can deploy it on the AdminServer and use it from a browser at https://<your-host>/rconsole/, with no desktop install. It is not deployed in the image, so nothing extra is exposed until you choose to deploy it.

Deploy it with WLST as the oracle user. The password is handed over in a file that only oracle can read, as in Step 8, and the deployment takes about 30 seconds:

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-rconsole.py <<'PY' import os f = open(os.environ['PWF']); pw = f.read().strip(); f.close() connect('weblogic', pw, 't3://127.0.0.1:7001') deploy('wls-remote-console', '/u01/app/oracle/product/wlserver/server/lib/wls-remote-console.war', targets='AdminServer', upload='false') print('Deployed: ' + str(cmo.lookupAppDeployment('wls-remote-console').getName())) disconnect() PY chmod 0644 /tmp/wlst-rconsole.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-rconsole.py 2>&1 | grep -E 'Deployment State|Deployed:'
sudo rm -f "$PWF" /tmp/wlst-rconsole.py
H=$(sudo cat /etc/sac/weblogic-host)
curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" --cacert <(sudo cat /etc/nginx/ssl/weblogic.crt) --resolve "$H:443:127.0.0.1" "https://$H/rconsole/"

Deployment State : completed Deployed: wls-remote-console 302 https://ec2-35-175-233-6.compute-1.amazonaws.com/rconsole/signin/index.html

Open https://<your-host>/rconsole/ and sign in as weblogic with the password from Step 4.

Choose This Server under Providers, then choose a tree. Use Edit Tree to change the configuration, Monitoring Tree for runtime state, and Security Data Tree for users, groups and policies.

The red Security warnings detected banner is WebLogic's own configuration check. On this image it lists two items that follow from the design (HTTPS is terminated by nginx and the AdminServer has no SSL listener), explained in Step 12. The hosted console signs you out after 10 minutes of inactivity.

Because the hosted console is a sign-in page on port 443, keep 443 limited to your administration networks while it is deployed. Remove it when you no longer need it with WLST undeploy('wls-remote-console').

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 the password 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 15.1.1.0.0 Wed Oct 01 23:34:34 GMT 2025 2196592", "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": "15.1.1.0.0", "name": "base_domain" }

You can make the same request from a browser signed in as weblogic.

A request without credentials is refused (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-35-175-233-6.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 that only oracle can read, never on a command line or in an environment variable. It prints the domain and server state and 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 name:

sudo weblogic-set-host weblogic.example.com

This 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, 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:

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 the command line history of other users. WebLogic locks an account for 30 minutes after five wrong passwords in a row.

This image is built from Oracle's WebLogic Server 15.1.1.0.0 base release with no Patch Set Update (PSU) or other Oracle patch applied, because 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, following Oracle's patching documentation for Oracle Fusion Middleware (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, and 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, or you can 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, with dnf-automatic daily or with sudo dnf -y update.

Check the installed versions and the JDK that 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 15.1.1.0.0 Wed Oct 01 23:34:34 GMT 2025 2196592 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.

Running WebLogic on Oracle JDK instead (Oracle support customers). Oracle's WebLogic Server 15.1.1 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.

1. Sign in to Oracle with your account, download the Oracle JDK 21 RPM for Linux x64 (jdk-21_linux-x64_bin.rpm) under the terms your Oracle license gives you, and copy the file to the instance.
2. Install the RPM 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}"

3. Point every place WebLogic reads JAVA_HOME at the new JDK (the systemd unit, the Oracle home, the domain scripts, the oracle user's profile and the SecureAnyCloud tools), and 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 the block. 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=168.63.129.16/32 fd00:ec2::254/128 169.254.169.254/32 IPAddressDeny=168.63.129.16/32 fd00:ec2::254/128 169.254.169.254/32

systemd may list the three addresses in a different order.

To see the block in action, run a request from inside each service's control group and one from your own session. The result 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, you can knowingly override the setting 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 at the top of every page, and the check is also available from the REST API. 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 also 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 and 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. HTTPS is terminated by nginx on port 443 and the AdminServer listens on 127.0.0.1:7001 only, so 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 15.1.1 generates them, with the rest of the domain, on your instance's first boot, so 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). Doing so also clears this item.