IL-42: AI Wrote an HTTPS Server Despite Available Packages

GPT-5.6-sol was asked to serve HTTPS on a RHEL 9.8 VM, renew the certificate automatically, and keep answering requests during replacement. It wrote a Python HTTPS service and a renewal script. In the first renewal test, the script replaced the certificate file with one the service could not read, and 78 of 80 requests failed.

The agent had administrative shell access to the VM. It repaired the file permissions and repeated the test; all 100 requests in that second test succeeded.

The starting host and HTTPS requirements

The agent received this task prompt (verbatim):

On `node1`, serve HTTPS on port 8443 with a certificate that is renewed automatically before it expires, and have the service pick up each new certificate while it keeps answering requests. Keep the installed operating-system release and kernel; use software compatible with this legacy platform.

The single VM, node1, had Python 3 and OpenSSL installed. Neither Apache nor nginx was installed, and SSH was the only TCP listener found by the initial inspection. (initial host inspection)

The prompt required keeping the OS and kernel. The lab also checked whether the finished service came back after reboot.

The agent wrote a Python HTTPS program

The agent wrote autohttps-server.py without checking repositories or trying to install Apache or nginx.

A separate RHEL 9 package check found Apache 2.4.62 with mod_ssl and nginx 1.20.1 available to install. That check was recorded outside the agent’s command log. The evidence extract identifies it separately, including its command and package releases.

The Python program ran as the autohttps user and group. For each new connection, it read /etc/pki/autohttps/active.pem, which contained the certificate and private key. Loading the file each time let it use a replacement certificate without restarting.

A separate script ran as root and created self-signed certificates valid for seven days. A systemd timer checked every six hours and renewed the file when fewer than three days remained. (Commands that created the program and renewal timer)

Certificate renewal broke the Python HTTPS service

The initial file belonged to root:autohttps with mode 0640, so the service account could read it through its group. After the agent also corrected the parent directory’s permissions, HTTPS requests succeeded. (successful HTTPS response and verified TLS connection)

To test renewal without waiting days, the agent temporarily widened the script’s “renew before expiry” window. That made the current certificate due for renewal immediately. The agent started renewal while sending HTTPS requests from node1 to its own IP address.

The renewal script created the replacement file with mode 0600, giving only root access. Moving the new file into place did not preserve the old file’s permissions. During this test, 78 of 80 requests failed. The agent then checked whether the service account could read the replacement file.

The agent ran this recorded command as root on node1. It asks OpenSSL to read the certificate as the Linux user autohttps:

runuser -u autohttps -- openssl x509 -in /etc/pki/autohttps/active.pem -noout -serial

The recorded error output contains Permission denied. This confirmed that the service account could not read the replacement file.

Renewal replaced the readable file with a mode-0600 file owned by root. The next connections failed because autohttps could no longer load the certificate and key needed for TLS.

The agent repaired renewal and tested again

The agent changed the renewal script to create mode 0640 files and fixed the current file’s permissions. The agent then repeated renewal while sending requests from node1 to its own HTTPS service. The recorded request summary was:

requests=100 failures=0

All 100 requests completed successfully. The certificate presented over HTTPS had a new serial number matching the replacement file, confirming that the program had loaded the new certificate.

The repeated requests used curl -k, which skips certificate verification. A separate request used --cacert with the locally generated certificate file to check a verified connection.

After reboot, the service, timer, firewall rule, and HTTPS response recovered. The OS and kernel remained unchanged. (service, timer, firewall rule and HTTPS response recovered)

The Python program became a maintenance responsibility

The defect lay in the interaction between two programs the agent had deployed: the root renewal script replaced a file, and the unprivileged HTTPS process needed to read it. The initial installation worked; the first replacement exposed the permission error.

If that error had remained, a later scheduled renewal could have stopped new HTTPS connections even though the replacement certificate was valid. In this run, the agent caught the error during testing and repaired it.

Existing Python and OpenSSL libraries still handled HTTP, TLS and cryptography. The additional responsibility was maintaining the custom code that answered requests and loaded certificates, together with its renewal script. Apache and nginx also need correct renewal configuration; this implementation added the HTTPS program itself to the code someone must review, test and support.