I'm using an internal API for some commercial software we purchased and it recommends using SSL when utilizing the API; it uses cURL to achieve this and hence the user, pass and key will all be passed to the cURL request.

We don't currently use SSL on the site for anything so didn't really want to purchase one just for this, but was told you could use a self-signed cert with no issues.

However upon doing research on them I found doing this creates issues for users sometimes, such as them getting a warning in their browser like:

enter image description here

My question though is, does these kind of errors/warning only occur when the user actually accesses the page themselves via https:// or will it also cause issues even though the SSL request is happening behind the scenes; I imagine it won't as wouldn't the web server itself be the one responsible for the request?

My next question regarding that is - if this falls back on the server itself, will it cause any issues for the server itself or stall things because of the self-signed cert or will things run without issue?

2 Answers 2


This error occurs when a browser encounters a certificate that it does not trust. By that I mean that the server's certificate is not installed as a trusted root certificate. These are handled different on a browser to browser basis, but generally the error message you see allows the user to add the un-trusted certificate to its trusted certificate store if they choose.

This error does only occur when the user tries to access the page via https://, or if you redirect your http:// page to the SSL/TLS enabled webpage. The server is responsible for handling the HTTPS request, and sending its certificate for validation. When the browser receives the certificate the following checks should happen:

  1. Does the browser recognize the certificate as a trusted certificate?
  2. Is the certificate expired or revoked?
  3. If the answer is no to both, then this message will be displayed.
  4. Now the user is given the option to continue to the website and/or install the certificate in its trusted store.

This will not stall things on the server side, and will run without error. The reaction to an un-trusted certificate depends upon the browser that is accessing the webpage. Regardless, most SSl/TLS protocol implementations will allow a certain amount of time for the client to respond to this message. If the user accepts the certificate as valid within the timeout window then the connection will proceed as normal. If they wait too long then the user will get a "session timeout" error, and they will have to reconnect to the website.

Curl automatically verifies server certificates. If you'd like to turn this off you can do this with -k or --insecure. Or you can add your server certificate to the trusted store.

Add Self Signed Certificate to cURL Trusted Store

The link above will take you through the steps of determining where on your Linux system the trusted certificates are stored, and how you can add your server's certificate to be trusted.

Since the commercial software is passing along arguments to cURL, I would expect that if cURL doesn't trust the certificate that it would fail. The user won't be able to access the page. It's also entirely possible that the software has mechanisms for handling this error. It may prompt the user to install the certificate, and continue the connection. Without knowing the software it's hard to say what its exact reaction will be.

  • So bottom line is that there won't be any issues caused by using a self-signed cert behind the scenes via cURL since the user isn't accessing it directly?
    – Brett
    Commented Sep 29, 2014 at 17:16
  • Not sure what you mean by "accessing it directly". I've updated my answer with some cURL specific work arounds to avoid getting this certificate message from cURL.
    – RoraΖ
    Commented Sep 29, 2014 at 18:41
  • Sorry by "directly" I meant the user isn't typing in or being redirected to a https page so they aren't directly accessing it; the request to the https page is happening inside the script via cURL; but from your response it sounds like cURL does attempt to verify it, so I guess my question is what happens if it fails?
    – Brett
    Commented Sep 30, 2014 at 5:11
  • Ah I see what you're saying. If the certificate isn't trusted and simply fails Steffen Ullrich has suggested; I would expect the user would not access the web page. The commercial software could handle this error, and ask the user if they would like to install the certificate. It might just be something you need to test out and see what happens.
    – RoraΖ
    Commented Sep 30, 2014 at 11:14
  • But that's what I'm saying, since the server is making the request to the https page what happens? Since the user isn't going to a https page in the browser themselves then they wouldn't see it, no!?
    – Brett
    Commented Sep 30, 2014 at 11:37

You get this warning usually only if you access the https site directly. If you try to access https behind the scenes, that is by doing an XMLHTTPRequest, embedding an image etc it will not ask the user, but instead simply fail (and usually log something to console).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .