IIIF media ingester gives sslcafile and sslcapath errors

Hello – I am struggling with ingesting media links to IIIF materials that are hosted on our ContentDM instance.

I have no issues when linking to IIIF media hosted at other institutions. I’ve tried the LOC and The Huntington with success.

However when trying to load an IIIF image from our digital collections at ccdl.claremont.edu (our library’s ContentDM site) I get this error:

<Error connecting to IIIF presentation: Unable to enable crypto on TCP connection ccdl.claremont.edu: make sure the “sslcafile” or “sslcapath” option are properly set for the environment.>

The sslcafile and sslcapath option are both currently set to null (the default). I’ve tried editing those paths but it hasn’t seemed to work.

The ingest not working on our site (but working fine on other IIIF hosts) suggests there may be more to it than just a missing certificate path on our Omeka S server?

Any advice welcome! Thanks!

I think I solved my own problem. :slight_smile:

Following up on a few conversations in StackOverflow – it looked like some of the Laminas utilities had been giving similar errors in other software packages. (Laminas is one of providers of code in Omeka S).

What I needed to do was edit the socket.php file (OmekaS/vendor/Laminas/laminas-http/src/Client/Adapter/socket.php):

In this code section:

 /**
     * Parameters array
     *
     * @var array
     */
    protected $config = array(
        'persistent'            => false,
        'ssltransport'          => 'ssl',
        'sslcert'               => null,
        'sslpassphrase'         => null,
        'sslverifypeer'         => true,
        'sslcafile'             => null,
        'sslcapath'             => null,
        'sslallowselfsigned'    => false,
        'sslusecontext'         => false
    );

sslverifyifpeer needed to be set to false.

Making this change will disable checking the server’s certificate when connecting to it, which will avoid the problem but isn’t ideal: you’re disabling some of the security of an HTTPS connection by doing this.

The problem here looks like it’s with the Claremont server you’re trying to connect to: it’s not sending the proper “intermediate” certificate like it should. You might try to report the problem to see if the people responsible for that server can fix it.

Yes – thanks. I’ve done a little more digging since last week and find out more about what this setting does.

I’ve met with our digital collections folks (who manage that site) and we’re following up with our IT and OCLC (ContentDM providers) to see what is going on with the certificate. This error message cropped up when the certificate was renewed at the end of last year.