Ws
Application Servers AWS

WebLogic Server 15.1.1.0.0 on AWS User Guide

| Product: WebLogic Server 15.1.1.0.0 on Oracle Linux 9 on AWS

Overview

This guide covers launching and using the WebLogic Server 15.1.1.0.0 on Oracle Linux 9 AMI from cloudimg on Amazon EC2. It is one version of the cloudimg Oracle WebLogic Server listing on AWS Marketplace; you pick it as the software version when you subscribe and launch.

Oracle WebLogic Server is Oracle's Jakarta EE application server: it runs enterprise Java applications, web services and messaging workloads with clustering, JDBC connection pools, JMS and a full security realm. Release 15.1.1.0.0 is a full Jakarta EE 9.1 platform (the jakarta.* namespace: applications built for the javax.* namespace of WebLogic 14.1.x must be migrated), supports Java SE 17 and 21, and is administered with the WebLogic Remote Console (the in-server Administration Console is no longer part of WebLogic Server).

The cloudimg image adds:

  • A domain made on your instance, not on ours. The image contains the WebLogic Server installation only. On the first boot of every instance, a one-time service creates base_domain from Oracle's own domain template with an administrator password generated on that instance. The domain's encryption salt (SerializedSystemIni.dat), its embedded LDAP store and its boot identity are therefore unique to your instance, and no two instances share a credential. The password never appears on a command line or in a log; it is written to /root/weblogic-credentials.txt (readable by root only).
  • Fail closed. WebLogic and the HTTPS front end refuse to start until first boot has finished. If first boot ever fails, the partial domain is removed and nothing listens.
  • HTTPS from the first boot. The AdminServer listens on 127.0.0.1:7001 only. nginx 1.26 serves it on port 443 with a certificate generated on your instance; port 80 redirects to HTTPS. Requests for a host name the instance does not serve get no answer, and WebLogic's internal servlets are not published.
  • Hardened defaults. Production mode, IIOP off, anonymous T3/IIOP RMI off and WebLogic's default internal servlets (HTTP tunnelling) off; WebLogic takes the client address from the connection, never from a header a client can forge; the /management/ API is rate limited. WebLogic and nginx are blocked from the instance metadata service and the AMI requires IMDSv2. SELinux stays enforcing, the oracle account has no password, and the server runs under a locked down systemd unit. The Derby demo database is never started.
  • Base media only. WebLogic Server is installed from Oracle's 15.1.1.0.0 release media (verified by checksum and by Oracle's code signature on the installer) with no PSU or other Oracle patch applied: you apply Oracle's patches with your own Oracle support (see Step 11).
  • Fully patched Oracle Linux 9 at build time, with dnf-automatic applying Oracle Linux security updates every day.

What is on the image: Oracle WebLogic Server 15.1.1.0.0 (WebLogic Server and Coherence) in /u01/app/oracle/product, Oracle JDK 21 (21.0.12.1) in /u01/java/jdk-21, nginx, Oracle Linux 9.8 with the Unbreakable Enterprise Kernel, cloud-init and the AWS Systems Manager agent.

Default user: ec2-user · Architecture: x86_64 · Recommended instance type: m5.large

Licensing

Oracle WebLogic Server is a commercial Oracle product. Using WebLogic Server requires your own Oracle WebLogic Server licence covering the instance under Oracle's cloud licensing policy; the cloudimg charge covers the hardened image, first-boot setup and support, not an Oracle licence. The image includes Oracle JDK 21 under the Oracle No-Fee Terms and Conditions as the Java runtime WebLogic Server is certified on (Oracle certifies WebLogic Server 15.1.1.0.0 on JDK 17 and JDK 21). The licence texts are in /usr/share/doc/cloudimg/licenses/.

Prerequisites

  • An AWS account subscribed to the listing, an EC2 key pair and a VPC subnet with a route to the internet (or a private route you use for management).
  • A security group that allows TCP 443 (HTTPS: WebLogic Remote Console, the REST management API and your applications) and TCP 80 (redirects to HTTPS) from the people and systems that use WebLogic, and TCP 22 (SSH) from your own networks only. Port 7001 is never needed in the security group.

Step 1: Launch the instance

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 and your Region, then Launch through EC2. Choose 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.

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}]'

Step 2: Connect to your instance

Version SSH user
WebLogic Server 15.1.1.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

Step 3: Check the services

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), then the AdminServer reaches RUNNING about 17 seconds later: WebLogic is ready three to four minutes after launch (measured on six fresh 2 vCPU, 8 GiB instances: 2 min 57 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-20T19:26:27Z] weblogic-firstboot: configured host: ec2-100-59-46-120.compute-1.amazonaws.com
[2026-10-20T19:26:27Z] weblogic-firstboot: creating base_domain (WLST offline from Oracle's wls.jar template)
[2026-10-20T19:28:51Z] weblogic-firstboot: TLS certificate + nginx host for ec2-100-59-46-120.compute-1.amazonaws.com
[2026-10-20T19:28:52Z] weblogic-firstboot: done in 145s; starting WebLogic and nginx

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

Step 4: Get your URL and password

The values generated for this instance are in a root-only file. This 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-20T19:28:52Z
WEBLOGIC_USER=weblogic
WEBLOGIC_PASSWORD=<hidden>
WEBLOGIC_ADMIN_URL=https://ec2-100-59-46-120.compute-1.amazonaws.com/
WEBLOGIC_REST_URL=https://ec2-100-59-46-120.compute-1.amazonaws.com/management/weblogic/latest
WEBLOGIC_WELCOME_URL=https://ec2-100-59-46-120.compute-1.amazonaws.com/console/welcome/
DOMAIN_HOME=/u01/app/oracle/product/user_projects/domains/base_domain
TLS_CERT_SHA256_FINGERPRINT=96:61:E8:67:A8:41:FD:DB:52:C8:38:33:6C:20:21:D7:80:1B:D2:14:E8:19:09:0C:98:7D:BF:19:36:10:67:86

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.

Step 5: Open WebLogic over HTTPS

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-100-59-46-120.compute-1.amazonaws.com
notAfter=Jan 22 19:28:52 2029 GMT
X509v3 Subject Alternative Name: 
    DNS:ec2-100-59-46-120.compute-1.amazonaws.com, IP Address:100.59.46.120, DNS:ip-172-31-82-89.ec2.internal, IP Address:172.31.82.89, 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/cloudimg/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-100-59-46-120.compute-1.amazonaws.com/

The certificate file is readable only by root and nginx, so these commands hand it to curl with sudo cat (it is a public certificate, not a secret).

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

The WebLogic Server 15.1.1 welcome page served over HTTPS, explaining that administration uses the WebLogic Remote Console, with a Download WebLogic Remote Console button

Step 6: Administer the domain with WebLogic Remote Console

Desktop Remote Console. 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-100-59-46-120.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 tick Make Insecure Connection after you have compared the fingerprint. 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) that you can deploy on the AdminServer and use 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 with WLST as the oracle user (the password is handed over in a file readable only by oracle, as in Step 8; this 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/cloudimg/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-100-59-46-120.compute-1.amazonaws.com/rconsole/signin/index.html

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

The Hosted WebLogic Remote Console sign-in page of WebLogic Server 15.1.1, served by the instance over HTTPS

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

The Hosted WebLogic Remote Console 2.4.18 Monitoring Tree showing the AdminServer of base_domain in the Running state

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 it is a sign-in page on port 443, keep 443 limited to your administration networks while it is deployed, and remove it when you no longer need it with WLST undeploy('wls-remote-console').

Step 7: Use the REST management API

The REST management API uses the same administrator credentials. This 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/cloudimg/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/cloudimg/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"
}

The same request from a browser signed in as weblogic:

The REST management API in a browser showing the AdminServer RUNNING on WebLogic Server 15.1.1.0.0

A request without credentials is refused (401), and the instance carries a self-test that proves the password, the anonymous refusal and a wrong-password refusal in one go:

H=$(sudo cat /etc/cloudimg/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-100-59-46-120.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 (WebLogic's own protection against cross-site requests).

Step 8: Script administration with WLST

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), prints the domain and server state, and 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().

Step 9: Your own DNS name and certificate

Point your DNS name at the instance, then run (replace the name):

sudo weblogic-set-host weblogic.example.com

This generates a new self-signed certificate for the name, adds it to nginx, sets it as WebLogic's front-end host, updates the URLs in /root/weblogic-credentials.txt and restarts the AdminServer (about a minute). To use a certificate from your own certificate authority instead, replace /etc/nginx/ssl/weblogic.crt and /etc/nginx/ssl/weblogic.key (key owned by root:nginx, mode 0640) after running the command, then sudo systemctl reload nginx.

Step 10: Change the administrator password

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), 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.

Step 11: Apply Oracle patches and Java updates

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, then start it again.

Oracle JDK 21 is in /u01/java/jdk-21.0.12.1 with the /u01/java/jdk-21 link that WebLogic uses. To move to a newer Oracle JDK 21 update under the terms your Oracle licence allows, unpack it beside the current one and point the link at it, then restart WebLogic. Oracle Linux packages, including nginx, are updated by dnf-automatic (security errata, daily) or with sudo dnf -y update.

Check the installed versions:

sudo setpriv --reuid=oracle --regid=oinstall --init-groups /u01/java/jdk-21/bin/java -cp /u01/app/oracle/product/wlserver/server/lib/weblogic.jar weblogic.version | grep 'WebLogic Server'
/u01/java/jdk-21/bin/java -version 2>&1 | head -1
WebLogic Server 15.1.1.0.0  Wed Oct 01 23:34:34 GMT 2025 2196592
java version "21.0.12.1" 2026-08-18 LTS

Step 12: Check the security model

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

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 (the AdminServer, every application you deploy, the nginx master and workers) is blocked from the instance metadata service, while the rest of the instance can still use it (first boot uses it to find the host name). On Oracle Linux 9 this is enforced by systemd: 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 it, run a request from inside each service's control group and one from your own session (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, or knowingly override the setting with sudo systemctl edit weblogic.service (an empty IPAddressDeny= line clears it). SELinux is enforcing:

getenforce
Enforcing

WebLogic's own security check is shown by Remote Console as a banner at the top of every page and 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), and 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/cloudimg/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: cloudimg" -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), which also clears this item.

Managing the WebLogic services

The AdminServer and nginx are ordinary systemd services:

sudo systemctl status weblogic.service --no-pager --lines=0 | head -4
● weblogic.service - Oracle WebLogic Server 15.1.1.0.0 AdminServer (base_domain, loopback 127.0.0.1:7001)
     Loaded: loaded (/etc/systemd/system/weblogic.service; enabled; preset: disabled)
    Drop-In: /etc/systemd/system/weblogic.service.d
             └─50-cloudimg-imds-deny.conf

Use sudo systemctl restart weblogic.service, stop or start as needed; the AdminServer is back in RUNNING about 30 seconds after a start. The server log is servers/AdminServer/logs/AdminServer.log under the domain, and the HTTP access log (with the real client address) is servers/AdminServer/logs/access.log. The AdminServer's Java heap is set in the unit (USER_MEM_ARGS=-Xms512m -Xmx2g); raise it with sudo systemctl edit weblogic.service for larger instance types.

NodeManager is not configured in this single-server domain. If you add managed servers on this host, configure NodeManager to listen on 127.0.0.1 with its own credential, and keep port 5556 out of the security group.

Filesystem layout

Path Purpose
/u01/java/jdk-21 Oracle JDK 21 (link to /u01/java/jdk-21.0.12.1)
/u01/app/oracle/product Oracle home (MW_HOME)
/u01/app/oracle/product/wlserver WebLogic Server (WL_HOME)
/u01/app/oracle/product/user_projects/domains/base_domain Your domain (DOMAIN_HOME), created on first boot
/u01/app/oraInventory Oracle inventory
/root/weblogic-credentials.txt This instance's credentials (root only)
/etc/nginx/ssl/weblogic.crt, weblogic.key This instance's TLS certificate and key
/etc/nginx/conf.d/weblogic-host.conf nginx site for the configured host (written by first boot and weblogic-set-host)
/usr/local/sbin/weblogic-set-host, weblogic-selftest Change the host name; prove the login path
/var/log/weblogic-firstboot.log First boot log
/usr/share/doc/cloudimg/licenses/ Oracle notices and the Oracle JDK licence

The oracle user's ~/.bash_profile exports JAVA_HOME, MW_HOME, ORACLE_HOME, WL_HOME and DOMAIN_HOME.

Troubleshooting

The AdminServer does not start. Check the unit and the server log:

sudo journalctl -u weblogic.service -n 20 --no-pager

weblogic.service and nginx.service only start after first boot has created /var/lib/cloudimg/weblogic-firstboot.done and the domain. If that file is missing, read /var/log/weblogic-firstboot.log.

The browser shows 502 Bad Gateway, or port 443 refuses the connection. First boot or the AdminServer is still starting (about three minutes after launch); wait a minute and reload.

No answer at all on 443 from your workstation. Check that the security group allows your address on 443, and that you use a host name the instance serves (the instance's public DNS name, its public or private address, or the name you set with weblogic-set-host).

Security recommendations

  • Allow 443 only from the networks that use WebLogic, and 22 only from your administration networks.
  • Replace the self-signed certificate with one from your certificate authority for production (Step 9).
  • Create separate users and groups in the security realm for operators and deployers instead of sharing the weblogic account.
  • Apply Oracle's WebLogic PSUs and Critical Patch Updates with your Oracle support entitlement (Step 11).

Support and licensing

cloudimg provides 24/7 technical support for this image by email and live chat: support@cloudimg.co.uk or www.cloudimg.co.uk/support. Licensing questions about Oracle software go to Oracle.

Using Oracle WebLogic Server requires your own Oracle licence; Oracle JDK 21 is included under the Oracle No-Fee Terms and Conditions. Oracle WebLogic Server documentation is at docs.oracle.com.

Oracle, Java and WebLogic are registered trademarks of Oracle and/or its affiliates. cloudimg is not affiliated with or endorsed by Oracle.