WebLogic Server 14.1.2.0.0 on Oracle Linux 8

In the AWS Marketplace listing, choose Continue to Subscribe, then Continue to Configuration. Pick WebLogic Server 14.1.2.0.0 on Oracle Linux 8 as the software version, pick your Region, then 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 instead, 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}]'

The SSH user for WebLogic Server 14.1.2.0.0 on Oracle Linux 8 is ec2-user. Connect with your key pair:

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

Confirm the operating system release:

cat /etc/oracle-release

Oracle Linux Server release 8.10

On a newly launched instance, first boot creates the domain in two to three 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 15 to 20 seconds later, so WebLogic is ready roughly three to four minutes after launch. On two fresh 2 vCPU instances, boot to RUNNING took 3 min 10 s and 3 min 47 s.

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:

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

[2026-10-23T15:16:47Z] weblogic-firstboot: configured host: ec2-54-152-228-170.compute-1.amazonaws.com [2026-10-23T15:16:47Z] weblogic-firstboot: creating base_domain (WLST offline from Oracle's wls.jar template) [2026-10-23T15:19:01Z] weblogic-firstboot: TLS certificate + nginx host for ec2-54-152-228-170.compute-1.amazonaws.com [2026-10-23T15:19:03Z] weblogic-firstboot: done in 136s; 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. Show 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-23T15:19:03Z WEBLOGIC_USER=weblogic WEBLOGIC_PASSWORD=<hidden> WEBLOGIC_ADMIN_URL=https://ec2-54-152-228-170.compute-1.amazonaws.com/ WEBLOGIC_REST_URL=https://ec2-54-152-228-170.compute-1.amazonaws.com/management/weblogic/latest WEBLOGIC_WELCOME_URL=https://ec2-54-152-228-170.compute-1.amazonaws.com/console/welcome/ DOMAIN_HOME=/u01/app/oracle/product/user_projects/domains/base_domain TLS_CERT_SHA256_FINGERPRINT=AD:88:AC:E3:B4:2E:62:FD:B7:51:50:E3:AF:20:89:46:B1:78:88:13:42:55:43:CF:F5:E6:0D:DD:54:03:6B:8D

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. Inspect 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-152-228-170.compute-1.amazonaws.com notAfter=Jan 25 15:19:02 2029 GMT X509v3 Subject Alternative Name: DNS:ec2-54-152-228-170.compute-1.amazonaws.com, IP Address:54.152.228.170, DNS:ip-172-31-82-205.ec2.internal, IP Address:172.31.82.205, 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. Confirm both:

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-152-228-170.compute-1.amazonaws.com/

In your browser, open the WEBLOGIC_WELCOME_URL from Step 4, and accept the self-signed certificate after checking 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 these values:

• URL: the WEBLOGIC_ADMIN_URL from Step 4 (for example https://ec2-54-152-228-170.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 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. The command below 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" }

Query 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" }

You can send 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-54-152-228-170.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. The example below 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 run connect('weblogic', '<password>', 't3://127.0.0.1:7001'), edit() and startEdit(), make your changes, and finish with save() and activate().

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

sudo weblogic-set-host weblogic.example.com

The command generates a new self-signed certificate for the name and adds it to nginx. It also sets the name as WebLogic's front-end host, 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 that 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 off 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 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 that 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 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 14.1.2.0.0 Tue Nov 26 02:40:45 GMT 2024 2171472 java-21-openjdk-headless-21.0.12.1.1-1.1.0.1.el8.x86_64 /usr/lib/jvm/java-21-openjdk-21.0.12.1.1-1.1.0.1.el8.x86_64 AdminServer JVM: java.home=/usr/lib/jvm/java-21-openjdk-21.0.12.1.1-1.1.0.1.el8.x86_64 (java-21-openjdk-headless-21.0.12.1.1-1.1.0.1.el8.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. java.vendor reads "Red Hat, Inc." because Oracle Linux rebuilds the same OpenJDK sources. The package itself is Oracle Linux's, with vendor Oracle America.

Optional: 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 licence gives you. Then copy it to the instance.
• 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}"

• Point every place that WebLogic reads JAVA_HOME at the new directory (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. List the listeners:

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. The first line of /etc/ssh/sshd_config includes that file so that sshd reads it before anything else (sshd keeps the first value it reads, and Oracle Linux 8's own sshd_config turns X11 forwarding on further down). sshd -T shows the values that 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

Processes running as oracle (the AdminServer, WLST and every application you deploy) and as nginx cannot reach the instance metadata service. Root still can, because first boot uses it to find the host name.

Oracle Linux 8 uses the legacy cgroup v1 hierarchy, where systemd does not enforce IPAddressDeny=. The block is therefore enforced by the host firewall, by owner. The units still carry IPAddressDeny=, which takes effect if you move the instance to cgroup v2. In the output below, 000 means no answer:

sudo setpriv --reuid=oracle --regid=oinstall --init-groups curl -s -m 5 -o /dev/null -w "oracle: %{http_code}\n" -X PUT -H "X-aws-ec2-metadata-token-ttl-seconds: 60" http://169.254.169.254/latest/api/token
sudo curl -s -m 5 -o /dev/null -w "root: %{http_code}\n" -X PUT -H "X-aws-ec2-metadata-token-ttl-seconds: 60" http://169.254.169.254/latest/api/token
sudo firewall-cmd --direct --get-all-rules

oracle: 000 root: 200 ipv4 filter OUTPUT 0 -m owner --uid-owner oracle -d 169.254.169.254/32 -j REJECT --reject-with icmp-port-unreachable ipv4 filter OUTPUT 0 -m owner --uid-owner oracle -d 168.63.129.16/32 -j REJECT --reject-with icmp-port-unreachable ipv4 filter OUTPUT 0 -m owner --uid-owner nginx -d 169.254.169.254/32 -j REJECT --reject-with icmp-port-unreachable ipv4 filter OUTPUT 0 -m owner --uid-owner nginx -d 168.63.129.16/32 -j REJECT --reject-with icmp-port-unreachable ipv6 filter OUTPUT 0 -m owner --uid-owner oracle -d fd00:ec2::254/128 -j REJECT ipv6 filter OUTPUT 0 -m owner --uid-owner nginx -d fd00:ec2::254/128 -j REJECT

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, remove the two oracle rules deliberately with sudo firewall-cmd --permanent --direct --remove-rule ... followed by sudo firewall-cmd --reload.

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 built-in servlets disabled (DefaultInternalServletsDisabled, which turns off T3/IIOP tunnelling over HTTP and clears warning 091031). nginx answers 404 for WebLogic's built-in 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, 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 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 therefore 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). This also clears the item.