I try to post to my Wordpress site using the RWordpress package (https://github.com/duncantl/RWordPress). This worked until recently, and I now get the following error message.
options(WordPressLogin = c(bla = 'fasel'),
WordPressURL = 'https://www.econinfo.de/xmlrpc.php')
getRecentPostTitles()
Error in function (type, msg, asError = TRUE) :
error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
Searching around, it seems that there is a conflict with the TLS version, but I don't understand on what side. The certificate from my hoster supports TSL 1.1 and TLS 1.2.
Any help would be appreciated.
I'm on Win 10 with
> RCurl::curlVersion()
$age
[1] 3
$version
[1] "7.40.0"
$vesion_num
[1] 468992
$host
[1] "x86_64-pc-win32"
$features
ssl libz ntlm asynchdns spnego largefile idn sspi
4 8 16 128 256 512 1024 2048
$ssl_version
[1] "OpenSSL/1.0.0o"
The RWordpress package has not been touched for over 7 years. You might want to explore other options.
These days, people use the curl or httr package for internet access. The RCurl package has been unmaintained for years unfortunately, and it only supports very old version of SSL (apparenlty not TSL 1.1 and TLS 1.2)
As you are using Windows 10 you can eventually download IIS Crypto and easily manage and disable TLS and SSL.
But #Jeron is right, RWordpress is deprecated.
Related
I setup my jdk provider by
Security.addProvider(new BouncyCastleFipsProvider()).
Set it in the Grpc client by:
SslContextBuilder sslContextBuilder = SslContextBuilder.forClient()
.sslProvider(SslProvider.JDK)
.applicationProtocolConfig(new ApplicationProtocolConfig(
ApplicationProtocolConfig.Protocol.ALPN,
ApplicationProtocolConfig.SelectorFailureBehavior.NO_ADVERTISE,
ApplicationProtocolConfig.SelectedListenerFailureBehavior.ACCEPT,
Collections.singletonList("h2")));
When trying to establish the connection, After successful ssl handshake I get:
UNAVAILABLE: Failed ALPN negotiation: Unable to find compatible protocol
Channel Pipeline: [SslHandler#0, ProtocolNegotiators$ClientTlsHandler#0, WriteBufferingAndExceptionHandler#0, DefaultChannelPipeline$TailContext#0]
I'm using grpc 1.44 version + bc-fips.jar 1.0.2 version.
Running my app by java 11.0.15 compiled by jdk1.8.0_291.jdk.
It looks like BouncyCastleFipsProvider, by its SSLParamertesUtil class, somehow remove the "h2" from the suggested application protocols list.
increasing grpc version to 1.46 didn't help.
Any suggestions please?
Thanks.
Server SSL Protocols: TLS 1.1, TLS 1.2 are enabled in the server
Works with REDCapR library which is using the same handshake protocol. I've verified the request headers with the fiddler tool. This proves that the server is accepting sslv3 alert handshakes successfully. I'm not sure why RCurl is failing for the same protocol.
Let me know if you need any more information. Thanks in advance!
Curl - Version 3.2,
RCurl - Version 1.95-4.11,
httr - Version 1.3.1,
openssl - Version 1.1
I'm trying to fetch the following URL via various libraries and command-line tools, but running into a SSL handshake error.
> curl https://www.joelosteen.com/Views/RSS/Feed?t=PodcastVideo&ct=CustomList&cst=Podcasts
curl: (35) error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error
I've seen here it may be fixed by reducing possible ciphers, but trying this less strict call with restricted ciphers doesn't fix it.
curl -vlkL "https://www.joelosteen.com/Views/RSS/Feed?t=PodcastVideo&ct=CustomList&cst=Podcasts" --ciphers DHE-RSA-AES256-SHA
Any ideas how I can fix this? It's a shared account, ie no root available.
The server supports only TLS version 1.2, i.e. no TLS 1.0 or even SSL 3.0. My guess is that the curl you use is simply too old to use TLS 1.2, but without further details about the version you use this guess can not be verified.
To determine the version of curl use curl --version. If you see it is compiled with OpenSSL than it should show at least version 1.0.1 of OpenSSL to have TLS 1.2 support.
curl -vlkL ... --ciphers DHE-RSA-AES256-SHA
This is not a cipher supported by the server. One of the ciphers supported is AES128-SHA but again, no chance if your curl does not support TLS 1.2.
I'm trying to get devtools::install_github() working behind my corporate proxy on Windows 7.
So far I've had to do the following:
> library(httr)
> library(devtools)
> set_config(use_proxy("123.123.123.123",8080))
> devtools::install_github("rstudio/ggvis")
Installing github repo ggvis/master from rstudio
Downloading master.zip from https://github.com/rstudio/ggvis/archive/master.zip
Error in function (type, msg, asError = TRUE) :
SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Apparently we have some kind of certificate server replacing SSL certs with our own corporate SSL certs (confirmed by going to https://github.com and examining the cert).
Anyhow, just wondering if there's a way to ignore that cert error and proceed with the installation?
One way to handle the problem is to set the CURLOPT_SSL_VERIFYPEER to false. This option determines whether curl verifies the authenticity of the peer's certificate. A value of 1 means curl verifies; 0 (zero) means it doesn't.
http://curl.haxx.se/libcurl/c/CURLOPT_SSL_VERIFYPEER.html
The relevant option needs to be passed to RCurl. In RCurl the CURLOPT_ is removed letters arre lowercase and the underscore is changed to ..
set_config( config( ssl.verifypeer = 0L ) )
will pass the relevant option to RCurl when using httr.
UPDATE:
The httr since this answer was written has moved from RCurl as an underlying dependence to the curl package. cURL options are now specified
with underscores so the above would be:
set_config( config( ssl_verifypeer = 0L ) )
in the current version of httr.
I tired #jdharrisonbut method but it didn't worked for me.
A Quick fix to avoid using https connection, is by replacing https by http. you install a package from cran by this method.
install.packages("http://cran.r-project.org/src/contrib/ggvis_0.4.4.tar.gz", repo=NULL, type="source")
I am having problems getting RCurl function getURL to access an HTTPS URL on a server that is using a self-signed certificate. I'm running R 3.0.2 on Mac OS X 10.9.2.
I have read the FAQ and the curl page on the subject. So this is where I stand:
I have saved a copy of the certificate to disk (~/cert.pem).
I have been able to use this very same file to connect to the server using python-requests and the 'verify' option, and succeeded.
curl on the command-line seems to be ignoring the --cacert option. I succeeded in accessing the website with it after I flagged the certificate as trusted using the Mac OS X 'Keychain Access' app.
RCurl stubbornly refuses to connect to the website with the following code:
getURL("https://somesite.tld", verbose=T, cainfo=normalizePath("~/cert.pem"))
This is the output I get:
* Adding handle: conn: 0x7f92771b0400
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 38 (0x7f92771b0400) send_pipe: 1, recv_pipe: 0
* About to connect() to somesite.tld port 443 (#38)
* Trying 42.42.42.42...
* Connected to somesite.tld (42.42.42.42) port 443 (#38)
* SSL certificate problem: Invalid certificate chain
* Closing connection 38
When I tested both curl with the --cacert option and the RCurl code above in a Linux VM with the same cert.pem file and exact same URL, it worked perfectly.
So equal tests on Linux and Mac OS X, and only on Mac OS X do they fail. Even adding the certificate to the keychain didn't work.
The only thing that does work is using ssl.verifypeer=FALSE, but I don't want to do that for security reasons.
I'm out of ideas here. Anyone else have any suggestions on how to get this to work?
You can try:
library ("RCurl")
URL1 <- "https://data.mexbt.com/ticker/btcusd"
getURL(URL1,cainfo=system.file("CurlSSL","cacert.pem",package="RCurl"))
Coming back to this issue I just wanted to point out that if you are still using RCurl, you should be using httr (which uses curl) instead.
I have confirmed that using config(cainfo="/path/to/certificate") with httr connections will work as intended.