I want to serve bokeh charts using the building server option.
As specified in the doc, one can use the option --ssl-certfile /path/to/pem/cert in order to serve it as an SSL termination point.
A Bokeh server can also terminate SSL connections directly by specifying the path to a single file in PEM format containing the certificate as well as any number of CA certificates needed to establish the certificate’s authenticity:
bokeh serve --ssl-certfile /path/to/cert.pem
However, if I try this
bokeh serve --ssl-certfile /Users/me/cert.pem
, I get:
error: unrecognized arguments: --ssl-certfile
I use the latest bokeh version 1.3.4
Any idea of what is happening???
Thanks,
Arnaud
This feature is not released yet. It will be in the next release version 1.4.
Edit: the way docs are hosted has recently changed completely, it looks like this information was accidentally published prematurely.
Related
I am posting this question on SO instead of ServerFault, because all my previous efforts to get Magento 2 issues sorted out, ended up being hacking some or other code in the Magento or template source.
I have configured a basic install of Magento 2 with a theme for a client.
Magento is running on IIS and Windows. (Not WAMP), shared IIS hosting on windows (My own server).
I configured the shop to use SSL, and the complete shop runs over SSL without any issues.
However, when trying to use the market place, I get a weird SSL issue:
"SSL certificate problem: unable to get local issuer certificate"
This error is shown on the Magneto shop (which is currently running over ssl), when trying to sign in to the market place.
I have found lots of hits on this issue, but all answers seem to lead to a self-signed certificate that isn't trusted or adding intermediary and/or root certificates. This is all based on XAMP, WAMP or native 'nix installations.
I do not understand what the exact issue is. I also do not know how to troubleshoot this further as the error description is very vague.
I would appreciate some feedback.
Thanks
This error happens because cURL cannot find a cacert.pem file from which take the trusted signatures.
There are some ways to set this file in cURL:
• Pass the cacert.pem file path directly to cURL when making the call;
• Set the path to the cacert.pem file in the php.ini.
You could follow below post:
• https://serverfault.com/questions/633644/adding-a-self-signed-cert-to-the-trusted-certs-within-curl-in-windows
• https://magento.stackexchange.com/questions/97036/magento-component-manager-ssl-certificate-problem-unable-to-get-local-issuer-c
• https://mage2.pro/t/topic/988
Regards,
Jalpa.
So with the help of Graham I realize I need to rebuild the mod_ssl.so to point to the new OpenSSL version.
I found the following post with similar problem but not much suggested: https://stackoverflow.com/questions/36756641/rebuild-mod-ssl-so-on-apache2-on-macosx
Is it possible to only rebuild the mod_ssl.so only or do I need to rebuild Apache?
Any specific flags to use?
Is homebrew the way o go and how do I avoid having two installations of Apache?
I am on 10.11.6 and using MacOS Server 5.2 (If that has an impact)
I have integrated the following framework under a flask app and made it work. https://github.com/playingmedia/swish-python
So basically it makes a Request with pyopenssl with included certificates.
This is working fine in my flask app, but when I move it to my Apache Server (configured to be accessed through TLS - not sure if that is relevant) it gives me the following error: SSLError: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:590)
I am wondering if there is mod_wsgi setting I need to manipulate of there could be any permission issues...
I included another framework using Suds with TLS without on the Apache server any problem so wondering if there is any known issues with Request library and pyopenssl under mod_wsgi?
Have tried to google quite a lot but perhaps I am not typing in the right key words
Thx
I recently had a need to upgrade an old server. The server fulfills a very specific purpose and as such has not been kept up to date. With the recent push for SSL to utilize SHA256 I needed to upgrade a few packages.
Short Background
The server is RHEL3 (yes, that is correct).
I downloaded and built OpenSSL 0.9.8q and ensured it was the only instance of OpenSSL on the server (moving the old instance to a backup directory). I then downloaded and built cURL 7.15.5 with the ./configure --with-ssl=/usr/local/ssl - pointing the with-ssl to my new OpenSSL directory.
Once cURL was built I tested my connection to the resource that is requiring sha256 using cURL. My connection test was successful using cURL.
On to my problem and question
I downloaded httpd 2.0.59 and built it with --enable-ssl and --enable-so, but my tests did not work.
I also tried to d/l & build httpd 2.0.63 but I was having trouble getting 2.0.63 working at all. I then took the mod_ssl built from 2.0.63 and put it into the 2.0.59 directory...no luck either.
I feel I am missing some element that connects httpd to my newly installed OpenSSL. What do I need to do to ensure mod_ssl is using my new version of OpenSSL on the server?
I understand I am quite a few releases behind with my httpd instances, but again, this is an old server with a specific purpose. My only goal is to get it working with sha256, not buy a new server with the latest RHEL, etc.
Thank for any input/assistance.
Running
./configure --help |grep ssl
gives
--with-ssl=DIR SSL/TLS toolkit (OpenSSL)
So just like the curl build you could try adding that.
Assuming you are not going to do the sensible thing and upgrade the OS.
I'm trying to update the ssl certificate for an app running on the bamboo-ree-1.8.7 stack.
When I try to simply list the current certificates heroku certs I encounter the error
The requested API endpoint was not found. Are you using the right HTTP verb (i.e. 'GET' vs. 'POST'), and did you specify your intended version with the 'Accept' header?
Thanks
Update to the latest Heroku toolbelt version. You may be using an old version that contains a reference to a deprecated path.
Also, I'm not sure if the fact you are still using the legacy bamboo stack matters in this case.
We are trying to use composite templates (fillable PDFs) and embedded signing using the REST API. We are using the docusign_rest gem in conjuction with our custom code to create composite templates and embedded signing. The docusign_rest gem is used for authentication and is giving the following error:
OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed)
On the local dev machine, we simply provided path to a certificate file at the time of starting the dev server, but on a remote machine this is not feasible.
Is it possible to skip the SSL check for a demo purpose? This SO link seems to suggest that it is possible. If yes, then how can we achieve that?
If not, then is there a quick way to fix it or do we have to install SSL certificates and configure the server to read those?
We are using ruby 1.9.3 , rails 3.2.11 and Apache2 (so that would mean enabling the SSL module).
I believe for demo (demo.docusign.net) you can use https OR http. What happens if you simply use http? Does that resolve your SSL error?
In either case, you'll eventually need to resolve this though because for production (www.docusign.net) you need to use https. The problem is most likely in your Ruby code or with your certificate. For testing purposes I'd try making a cURL request through the command line to see if that works.
See here for some examples of making DocuSign REST API calls using cURL