Configuring HTTPS Post request with no certificate

PAC Project
1

TL;DR - Using a SNAP PAC I’m trying to ping a local HTTP API that I can successfully access using Bruno, and the attempt is failing with a SSL Handshake error. (I think)

Details:
I have a device on the network with an HTTP accessible API. I can successfully access the device using Bruno (a standalone API tester) and the following parameters:

https://[destination ip address, no port number]/[api directory]
Header: “Content-Type: application/json”
Body: “[JSON string of API request info]”

Using these parameters I get back the expected response from the device.

I’m attempting to replicate this ping using the HTTPPostFromStringTable command in PACControl, however, I cannot successfully connect to the device. I have tried all four permutations of security mode 0 and 1, and HTTP port 80 and 443, and I get the following responses:

80, 0 : -412 Cannot Connect
80, 1: -412 Cannot Connect
443, 0: -443 Could Not Receive on Socket
443, 1: -2103 SSL Handshake Failed

Now, given that the API tester is using an https address for the request, I’m assuming that it’s connecting on port 443, so I’m guessing that the last case is the one I should focus on.

However, I want to be clear that the API tester doesn’t have a certificate associated with this device, nor does this API call require authentication - it works great from the API tester with no further credentials required.

Here’s my PAC Control code:

HTTP_Post_Content[0] = “[json of post request, with quotation marks painstakingly inserted as control characters]”;
HTTP_Post_Header[0] = “Content-Type: application/json”;

HTTP_SendStatus = HttpPostFromStringTable(
HTTP_Response_Content,
HTTP_Response_Header,
HTTP_Post_Content,
HTTP_Post_Header,
1,
“/api/[apidir]”,
HTTP_Status,
443,
“xxx.xxx.xxx.xxx”);

Am I missing something obvious? Thanks!

2

The last option you tried is correct (443, 1) for communicating over https. The PAC controller most likely doesn’t have the public certificate of the CA that was used to sign the certificate in the device API and will need to be loaded onto the controller.

See the section in the PAC Control User’s Guide (Document 1700) titled “Install a CA root certificate”.

3

I exported the certificate from the PLC and followed the instructions in the PAC Control guide to import it onto the SNAP-PAC. Still got the same error - handshake failed.

Here’s the network log from Bruno:

Preparing request to https://[ip address]/[api address]
Current time is 2025-08-18T16:27:46.622Z

POST https://[ip address]/[api address]

Accept: application/json, text/plain, */*
Content-Type: application/json
User-Agent: bruno-runtime/2.9.1

[api content]

SSL validation: disabled
ALPN: offers h2, http/1.1
Using system default CA certificates

Trying [ip address]:443...
Connected to [ip address] ([ip address]) port 443

SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 (TLSv1/SSLv3)
ALPN: server accepted None
Server certificate:
 subject: CN=[Certificate name]
 start date: Aug 12 23:06:57 2025 GMT
 expire date: Aug 12 07:00:00 2037 GMT
 subjectAltName: IP Address: [ip address], DNS:[same as ip address]
 issuer: CN=[Certificate name]
SSL certificate verify ok.

HTTP/1.1 200 OK

content-type: application/json
cache-control: no-cache
pragma: no-cache
expires: 0
access-control-allow-origin: *
access-control-allow-headers: Content-Type,X-Auth-Token
access-control-allow-methods: POST,OPTIONS
transfer-encoding: chunked
date: Mon, 18 Aug 2025 16:27:44 GMT
request-duration: 510

Request completed in 510 ms

[Certificate name] above is the same one I downloaded to the SNAP-PAC. I did reboot the SNAP and redownload the strategy before making the attempt.

4

I’m not certain if the PAC supports seeing the IP address in the subject alternative name - are you able to connect using the host name in the CN field instead of using the IP?

.Or create the devices certificate using the IP in the CN field.

5

I can’t use the host name - there is no DNS on this network. The control laptop with the HMI on it is directly connected to the PLCs via a local switch, and the entire system is air-gapped for security. The system isn’t large enough to warrant setting up a router with the attendant management overhead - a simple switch is all that’s needed.

I’ll take a stab at the second approach and report back.

6

Not having much luck. Is there any way to review the network log from the interaction so I can get a bit more information than just “handshake failed?”

I’m trying to export the certificate with just the IP address in the CN field, but the problem there is that you get a filename with a bunch of periods in it, which can potentially confuse the intervening file systems (particularly windows) as it passes through.

7

Since you don’t have a hostname on the local network, a new certificate would need to be created with the CN set to the IP of the API device and loaded onto the device. That wouldn’t have anything to do with the filename of the exported certificate which shouldn’t matter what it is called.

8

I’m trying to export the certificate with just the IP address in the CN field, but the problem there is that you get a filename with a bunch of periods in it,

But why are you trying to export a certificate with just the IP address in the CN field? An IP address isn’t assigned to a MAC address except in the router, and if that capability resides in the router, you might as well assign a host name to a MAC address in the router and use a host name based certificate. Also, you can configure most routers to allow only known MAC addresses on the network. Otherwise the certificate offers no real authentication of a node because any node can claim an IP address in a network without the aforementioned router configuration.

Doing this will also confirm or rule out the cause of your issue when you said, “a filename with a bunch of periods in it, which can potentially confuse the intervening file systems (particularly windows) as it passes through.”

9

There is no router on this network. It is just a few devices referring to each other by their statically asserted IP addresses via a dumb switch.

The other PLC has no difficulty at all querying the REST endpoint on the SNAP. I just need to figure out how to go the other way - querying the other PLC’s web API from the SNAP.

10

FWIW, I think I figured out what the issue is. I set up a managed switch and Wireshark, and managed to inspect the exchange between the SNAP and the other PLC.

It was failing at the Client Hello stage - so the certificate was never even sent. Rather, the list of ciphers being offered by the SNAP was so outdated that the fresh-out-of-the-box new PLC looked at them and said “Nope. Don’t trust ANY of those.”

I’m not sure there’s a solution here - I assume it’s unlikely a SNAP PAC R1 is getting any better ciphers on board any time soon, and I don’t think it’s possible to force the new PLC to accept a deprecated one.

11

If your understanding is correct, that’s something that should be fixed. I’d reach out to Opto support and let them know.