Connectivity failure (Timeout/HTTP 499) from Second Life region simulators to the external API (factorycasas.es)
complete
neofilo Aabye
- Overview of the problem
We are experiencing a persistent communication failure when our automated vendor within Second Life (through a POST request with LLHttpRequest) tries to communicate with our backend server located at https://factorycasas.es/Radio/Crear_Emisora.php.
Every transaction attempt from Second Life consistently results in an HTTP Status Code 499 (Customer closed the request/Timeout) on the LSL side, while conventional web browsers, API testing tools (such as Postman) and external HTTP clients can successfully access the endpoint, obtaining a 200 OK status in less than 50 milliseconds.
- Technical environment and architecture
Target endpoint: [https://factorycasas.es/Radio/Crear_Emisora .php]
SSL/TLS configuration: Valid certificate (Certbot/Let's Encrypt) with the complete intermediate chain configured correctly.
Backend optimization: The PHP script implements asynchronous execution in the background (fastcgi_finish_request (), ignore_user_abort () and CLI workers) to ensure that the HTTP 200 response is sent to the client instantly, eliminating any internal processing bottleneck.
- Symptoms and Diagnostic Findings
LSL behavior: When executing LLHttpRequest from a scripted object in the world, the request was blocked for approximately 25 seconds and was abruptly interrupted with HTTP 499, returning an empty response body (body: “”).
Network Interception Test:
When testing the endpoint using external web clients or curl from external networks, the response is immediate (HTTP/ 1.1 200 OK).
When monitoring network traffic using tcpdump on the VPS pointing to Linden Lab's known outbound IP ranges (64.129.x.x, 216.82.x.x, 162.243.x.x), incoming TLS handshakes or packets coming from Second Life regions are not recorded or appear to be completely discarded, strongly suggesting that outbound traffic from the SL simulator is being filtered, blocked or limited before reaching the server's public interface, or that the domain Destination /IP has been unintentionally marked or restricted in the simulator's outbound firewall.
Alternative access: Other domains hosted outside this VPS or specific network perimeter successfully receive callbacks (LLHttpRequest) from the exact same region without throwing error 499.
- Request for assistance
Since external HTTP access to factorycasas.es operates normally for all global traffic, with the exception of requests from Second Life simulator nodes, we kindly request your collaboration to:
Check if the domain factorycasas.es or the associated IP address of the VPS is currently restricted, rate-limited, or blacklisted within Linden Lab's outgoing proxy/firewall infrastructure.
Review possible output routing problems or incompatibilities in SSL/TLS ciphers between the simulator's HTTP client library and our server configuration.
Thank you in advance for your time and technical support.
I am at your disposal for any clarification.
Log In
This post was marked as
complete
Maestro Linden
neofilo Aabye we have updated the simulator's certificates package to include the CA used by factorycasas.es, which fixed issues with accessing https://factorycasas.es with the certificate that expired on Nov 10 23:59:59 2026 GMT.
However, it appears that factorycasas.es now has a new certificate, and that the server does not currently send the full SSL certificate chain down to clients. This causes a 499 when attempting to access with llHTTPRequest, but also when trying to validate the certificate with other clients such as openssl:
% openssl s_client -connect factorycasas.es:443 -servername factorycasas.es
Connecting to 46.27.131.17
CONNECTED(00000005)
depth=0 CN=factorycasas.es
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN=factorycasas.es
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN=factorycasas.es
verify return:1
---
Certificate chain
0 s:CN=factorycasas.es
i:C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV R36
a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Oct 28 00:00:00 2026 GMT; NotAfter: May 13 23:59:59 2027 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGizCCBPOgAwIBAgIRAIub5m1W/Mc5dthvr8ghGEowDQYJKoZIhvcNAQELBQAw
...
2ccE0/g73AmoNmFKAEuusYUfVxKCPNi4ug8US9c8OU5sCbQn19UgnKHV7QjyIbU=
-----END CERTIFICATE-----
subject=CN=factorycasas.es
issuer=C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV R36
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: rsa_pss_rsae_sha256
Negotiated TLS1.3 group: X25519MLKEM768
---
SSL handshake has read 3327 bytes and written 1658 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Protocol: TLSv1.3
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 21 (unable to verify the first certificate)
...
You need to modify the server to send the full SSL certificate chain in order for the site to become fully accessible over https.
Monty Brandenberg
Sorry, HTTP_EXTENDED_ERROR doesn't supply additional information in this case. Will turn that into a bug report as well.
Maestro Linden
updated the status to
tracked
Monty Brandenberg
neofilo Aabye Quick answer to this is that your SSL certificate is using a newer Certificate Authority. One that our HTTP-Out proxies do not yet have for validation.
You may be able to see an indication of this by using the Enhanced Error Reporting features in HTTP-Out. (But I am not certain of that without testing.)
Quick workarounds:
* Use insecure http:/ for the moment. I can see that this has been done three times in the past 96 hours resulting in 301 codes (almost certainly redirections to https:/). I don't recommend this.
* Use a cert from an older CA entity as a temporary measure.
* Disable cert verification in the request. Not ideal but you'll still have encryption this way.
We will get some updates to the proxies on the schedule and will followup in this report when updated.