With c$socket and 'ags-create-server' I have now created a simple server for receiving web server messages. However, they expected from us to work with ssl. c$socket was a simple way that made a web server unnecessary on our side. Does anyone have experience with a simple similar ssl server solution, without running a 'real' web server.

I'm afraid there is no such thing as a simple SSL-enabled (really, TLS-enabled; the "SSL" name was superseded in 1999) HTTP server. TLS is very complicated.

There are TLS servers that are a lot of work and require specialized knowledge; TLS servers that are broken; and TLS servers that someone else administers for you.

A properly-implemented and -administered HTTPS server will have a certificate (or certificates, if it supports both RSA and ECDSA suites) issued by an organizational or public CA, signed using an intermediate certificate, with a reasonably short expiration period. The CA will follow the CABF Baseline Requirements, so there are CRLs and OCSP and probably transparency logs to worry about. The server may have to implement OCSP stapling for performance reasons. The server's administrator will practice good private-key hygiene to prevent the key from being stolen. The server may enforce HTTP Strict Transport Security. The administrator will curate the set of supported TLS versions and cipher suites to include only those necessary for compatibility with authorized clients, and ensure that the available suites meet the organization's requirements for security. Someone will have to monitor updates to the server software, particularly the TLS implementation, so that security vulnerabilities are patched quickly.

Any "simple" TLS-enabled server will fail to do many of these things, and consequently be only marginally more secure than communicating in plaintext.

And so most applications take one of the other two choices.

---

With c$socket and 'ags-create-server' I have now created a simple server for receiving web server messages. However, they expected from us to work with ssl. c$socket was a simple way that made a web server unnecessary on our side. Does anyone have experience with a simple similar ssl server solution, without running a 'real' web server.

I suggest 2 possibilities. For the simple implementation you can look at the library routine and example program provided with Acucobol using RMNET. For more complex implementations maybe you could look at using a component from CHILLKAT Software. I have successfully implemented both options. (Please check which runtime version RMNET first appeared with)

---

With c$socket and 'ags-create-server' I have now created a simple server for receiving web server messages. However, they expected from us to work with ssl. c$socket was a simple way that made a web server unnecessary on our side. Does anyone have experience with a simple similar ssl server solution, without running a 'real' web server.

My opinion: anything except a real web server is a slippery slope. There will always be another problem to solve. Internet Information Server (IIS) is included for free with every copy of Windows newer than XP, and Micro Focus Business Information Server (BIS) for ACU runs under that (or Apache on UNIX) and does exactly what you are asking about -- allows you to run COBOL programs in the context of a web server. The web server handles all the plumbing. Besides SSL/TLS, there are other reasons to use a real web server, like user authentication, proper handling of proxies, resistance to DOS attacks, etc. You have access to the request headers and all of the HTTP(S) variables, but the request payload is decoded into XML for you and, with XML Extensions for ACU, can be decoded and plopped directly into your program's working storage for you. or you can read and write the XML request directly, if you prefer. Same for the response: data in working storage data can be transformed into a SOAP packet (or POX or JSON, if you prefer) using a stylesheet and BIS XML extensions handles whatever type conversions are required. COBOL just handles the business logic, which is what it's good at.

I'm guessing this is more than an in-house service behind a firewall or you wouldn't be considering using TLS at all.

---