I'm running Grafana 9.3.6 installed via apt-get on Ubuntu 20.04.5
I have a HiveMQ cloud broker I'm trying to connect to.
Previously I succeeded to connect via mosquitto command line tool and mosquittopp C++ interface. These required me to provide a certificate or certificate path.
I used the .pem file provided by HiveMQ with the command line tool.
I provided the /etc/ssl/certs/ path for the C++ interface (the 1st option did not work out)
Now I'm trying to connect via the Grafana MQTT plugin. I installed it using
grafana-cli plugins install grafana-mqtt-datasource.
When trying to add it in the web gui, I get the following error:
error connecting to MQTT broker: network Error : EOF
I can see some messages going back and forth in Wireshark so I assume the problem is with the certificates.
I tried editing the grafana.ini file without success. It's not completely clear which file/path should I add where and what other options I need to set.
Edit: the grafana.ini file had nothing to do with this.
As #hardillb pointed out, I had to pay attention to the URL scheme. After putting tls:// in front of the broker URL as described in grafana-mqtt-datasource, everything worked.
Related
I'm trying to setup a very basic wordpress setup as explained in this document: https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk
And cloud sql proxy is giving me certificate errors:
esonika#cloudshell:~ (esonika)$ k logs wordpress-8d7998ccd-xnfn9 -c cloudsql-proxy
2022/12/30 10:43:38 using credential file for authentication; email=cloudsql-proxy#esonika.iam.gserviceaccount.com
2022/12/30 10:43:38 Listening on 127.0.0.1:3306 for esonika:europe-west9:mysql-wordpress-instance
2022/12/30 10:43:38 Ready for new connections
2022/12/30 10:44:01 New connection for "esonika:europe-west9:mysql-wordpress-instance"
2022/12/30 10:44:02 couldn't connect to "esonika:europe-west9:mysql-wordpress-instance": x509: certificate is valid for 38-968d77ed-a928-4b25-97d3-5451b5f3c670.europe-west9.sql.goog, not esonika:mysql-wordpress-instance
I dont know why a certificate such as "38-968d77ed-a928-4b25-97d3-5451b5f3c670.europe-west9.sql.goog" is created and where.
Tried resetting ssl configurations and it didn't work.
Usually, if you don't explicitly set a SSL connection on your Cloud SQL instance, the communication with the database is in plain text.
EXCEPT when you create a tunnel with Cloud SQL proxy. This time, a secure connection is created, with encrypted data. The encryption is ensure by this automatically and ephemeral certificate created by the proxy.
Here is a doc which might help you in connecting to Cloud SQL from GKE using sidecar pods.
Thanks, The document doesn't list anything that I haven't tried. I think there is an internal issue with cloud_sql_proxy, that's why I decided to switch Cloud SQL to a private network only and wordpress pod is directly connecting to Cloud SQL private IP.
I was running into the same issue around the time you posted this question. I also reset SSL configuration on the DB like you did. My solution was upgrading from the version 1.11 to 1.33.2. It resolved all of the x509 errors. No clue why it suddenly stopped working.
Some background... I'm trying to run a nifi registry on ECS. I'm using the apache/nifi-registry:latest container image.
I'm unable to set this up via TLS (without baking my cert details into my dockerfile which is a security nightmare). Is there another way to still be able to use the registry with users/etc and NOT need to be running on HTTPS ports?
I'd prefer to run this container on port 18080 still, but it appears when doing so I'm unable to login/really do anything with nifi reg?
I basically follow the steps in this question to create SSL certificates for ActiveMQ. Now with some help, I can connect my C# application to ActiveMQ. However when I tried to connect my Angular application to it, I got ERR_CERT_COMMON_NAME_INVALID error.
I actually have an ActiveMQ instance running in AmazonMQ and it works fine with my Angular application. So I think this is the issue of the certificate when I try to run the ActiveMQ in my own docker image.
For some details, I am using a domain name dev.com pointing to 127.0.0.1, which is set in host file. I am using dev.com to access both C# application and Angular application so I plan to use wss://dev.com:61619 to access ActiveMQ from my Angular application. When I generate keystore, I specify dev.com as the CN. In addition, I have another self-signed certificate generated with OpenSSL for Angular and C# application, not sure if there will be any conflict between them.
Can anyone please help to see what could be wrong?
Thank you
I am trying to connect my NodeMCU ESP-12N to Azure IoT hub.
I have created client with code like this:
esp8266 = mqtt.Client(DEVICE, 240, USER, PASSWD)
and receiving error on calling esp8266:connect
PANIC: unprotected error in call to Lua API (init.lua:127: ssl not
available)
When I previously have connect my Arduino, then it was important to flash Wi-Fi with SSL certificate. However I can't do it with NodeMCU (or more right to say - don't know how).
I can get certificates with:
openssl s_client -showcerts -connect ArduinoDemoHub.azure-devices.net:8883
When I have add (thank you #MarcelStör for hint, I have tried previously net.cert.verify)
tls.cert.verify([[
-----BEGIN CERTIFICATE-----
MIIGsTCCBJmgADJKJFdWgAIQF5Koy/50vI3cQAAAAhAXjANBgkqhkiG9w0BAQsF
......
lz3ZDUcyzRgG6TRtA3SjASEUlJMt3f7xuI2nNpt8p5gy9pXuRw==
-----END CERTIFICATE-----
]])
tls.cert.verify(true)
I'v received another error:
Error Connecting: -5
UPDATE:
There is another similar topic, and I have set time, but still without result.
UPDATE 2:
Here are some links that I trying to use:
Use Azure IoT Hub without client libraries (MQTT)
Sending Device-to-Cloud (D2C) Messages
sankarcheppali gitHub with samples
Here is official Link
Communicate with your IoT hub using the MQTT protocol
that tells:
To use the MQTT protocol directly, your client must connect over
TLS/SSL. Attempts to skip this will fail with connection errors.
This link also provides username that is different from old code samples:
{iothubhostname}/{device_id}/api-version=2016-11-14
TLS/SSL by default is disabled in the firmware build configuration. CLIENT_SSL_ENABLE in user_config.h must be uncommented before compiling/building the firmware.
The easiest is to use the cloud builder at https://nodemcu-build.com (by yours truly) and check the TLS checkbox.
Also, all TLS/SSL related functions in the net module (you use net.cert.verify) were extracted into the tls module a while ago. Unless there's convincing arguments for not using a current firmware build I suggest you try the dev branch. When you enable "TLS/SSL support" in the builder you get the tls module automatically.
UPDATE: There is nice article about Azure IoT hub and certificates: Certificate between IoT hub and devices connection
I have created SAS with help of Device Explorer, that is looks like:
SharedAccessSignature sr={your hub name}.azure-devices.net%2Fdevices%2FMyDevice01%2Fapi-version%3D2016-11-14&sig=vSgHBMUG.....Ntg%3d&se=1456481802
This value is set to PASSWD variable. Have changed USER variable to:
USER = "MyAzureIoTHub.azure-devices.net/MyDeviceID/api-version=2016-11-14"
And has set to false tls.cert.verify
tls.cert.verify(false)
Works now :)
You can refer to the following two libraries to connect NodeMCU ESP-12N to Azure IoT hub, these two libraries could be searched in Library Manager:
AzureIoTHubMQTTClient
AzureIoTProtocol_MQTT
After installation,you can refer to the samples.
I am hoping someone can help me out with a frustrating configuration problem I'm having with IBM FileNet Content Manager 5.2.1 (aka P8 5.2.1).
We have an existing system setup that uses Microsoft Active Directory as our LDAP directory service for P8 and that has worked fine to date. That said, we are now wanting our .NET apps to talk to P8 (via the Content Platform Engine .NET API) using WCF instead of legacy (and now deprecated) WSE but we have run into a problem. WCF requires that all communication occur over SSL - on the surface, not a problem. If you want to talk to the IBM Content Platform Engine (CPE) over SSL however, according to IBM's documentation, you must also change the underlying default LDAP connection from unsecured to SSL as well (in the process, changing LDAP to use port 636 instead of 389).
Following both Microsoft's and IBM's docs, I first enabled LDAP over SSL on Active Directory and tested accordingly. Using Microsoft's LDAP utility, ldp.exe, I can successfully connect and bind to Active Directory on port 636 over SSL.
The next step however is where I hit a wall - Enabling SSL for Content Platform Engine. I followed all the steps involving adding the Active Directory Server's CA certificate to the CPE's application server keystore - no problem. The next step in the configuration instructions however asks you to start the Administration Console for CPE (ACCE) and reconfigure the directory configuration properties - telling it to use SSL on port 636 and... KABOOM! When I attempt to save the configuration, the save fails, stating
An unexpected exception occurred. Message was: Failed connecting to ldap://ad1.domain.com:636
Unfortunately, I can't find any additional info as to why it failed to connect - I assumed it was due to something minor, such as a port conflict. To test that theory, I installed Microsoft's LDAP test utility on the CPE server and attempted to connect to the Active Directory Server over SSL on port 636. Much to my surprise, that worked just fine - grrrr...
I am now at something of a loss as to what to look at next. Anybody out there with experience configuring CPE to use SSL in an Active Directory environment?
Thanks in advance for any-and-all assistance.
WCF requires that all communication occur over SSL - on the surface, not a problem. If you want to talk to the IBM Content Platform Engine (CPE) over SSL however, according to IBM's documentation, you must also change the underlying default LDAP connection from unsecured to SSL as well
This is not true. FileNet can work with non-secure LDAP, while at the same time working with WCF.
Now, if you would like to solve why FileNet will not connect to a secure LDAP, then you should start with your WebSphere
Check WebSphere's Keystores to ensure that the AD's key is contained. Follow #M.Tamboli's advice and restart WebSphere.
Also make sure that you check WebSphere's SystemOut.log logs, as you may find more info in there.
I'm not sure if it is necessary, but you may also want to add/change the LDAP config that is setup within WebSphere itself.