I'm trying to configure rsyslog tls with relp but keep getting errors.
I'm using RHEL 7.2 with rsyslog 8.15.
I do manage to send messages using relp + tls but without using the certificates. When I'm adding the certificates I'm getting the following error:
Jan 20 11:00:17 ip-10-0-0-114 rsyslogd-2353: imrelp[514]: error 'Failed to set certificate trust files [gnutls error -64: Error while reading file.]', object 'lstn 514' - input may not work as intended [v8.15.0 try http://www.rsyslog.com/e/2353 ]
Jan 20 11:00:17 ip-10-0-0-114 rsyslogd-2291: imrelp: could not activate relp listner, code 10031 [v8.15.0 try http://www.rsyslog.com/e/2291 ]
Server conf:
module(load="imrelp" ruleset="relp")
input(type="imrelp" port="514" tls="on"
tls.caCert="/home/ec2-user/rsyslog/ca.pem"
tls.myCert="/home/ec2-user/rsyslog/server-cert.pem"
tls.myPrivKey="/home/ec2-user/rsyslog/server-key.pem"
tls.authmode="name"
tls.permittedpeer=["client.example.co"]
)
ruleset(name="relp") {
action(type="omfile" file="/var/log/relptls2")
}
The following is the client configuration:
module(load="omrelp")
action(type="omrelp" target="10.0.0.114" port="514" tls="on"
tls.caCert="/home/ec2-user/rsyslog/ca.pem"
tls.myCert="/home/ec2-user/rsyslog/client-cert.pem"
tls.myPrivKey="/home/ec2-user/rsyslog/client-key.pem"
tls.authmode="name"
tls.permittedpeer=["server.example.co"]
)
When I remove the tls cert fields from the server configration I get client error:
Jan 20 10:35:29 ip-10-0-0-206 rsyslogd-2353: omrelp[10.0.0.114:514]:
error 'Failed to set certificate trust file [gnutls error -64: Error
while reading file.]', object 'conn to srvr 10.0.0.114:514' - action
may not work as intended [v8.15.0 try http://www.rsyslog.com/e/2353 ]
Help would be really really appreciated as I'm stack with this for long time.
Thanks!!!!
The gnutls error -64: Error while reading file error message means either:
The certificates actual path is different from what is in the
configuration file
Rsyslog service cannot read the certificates
because of permission problem
In case of permission issue you may move the certificates under /etc/rsyslog.d
In case of path issue, just fix the path :)
Related
I've try to apply my CA certificate to Solr. I've already reach solr with http or self-signed certificate following their own recipe in there: enabling ssl
But, when I try to apply my CA certificate I take an error : "HTTP ERROR 404 javax.servlet.UnavailableException: Error processing the request. CoreContainer is either not initialized or shutting down."
Full error message that I've take on browser
My solr.in.sh config is:
SOLR_SSL_ENABLED=true
SOLR_SSL_KEY_STORE=/etc/default/mykeystore
SOLR_SSL_KEY_STORE_PASSWORD=********
SOLR_SSL_TRUST_STORE=/etc/default/mykeystore
SOLR_SSL_TRUST_STORE_PASSWORD=********
SOLR_SSL_NEED_CLIENT_AUTH=false
# SOLR_SSL_WANT_CLIENT_AUTH=false
#SOLR_SSL_CLIENT_HOSTNAME_VERIFICATION=true
SOLR_SSL_CHECK_PEER_NAME=false
SOLR_SSL_KEY_STORE_TYPE=JKS
SOLR_SSL_TRUST_STORE_TYPE=JKS
I followed this two link for convert my pem file to key store: first:1 then:2 (I applied just fourth step in second link) then named the file as mykeystore.
I tried a lot of solution which some of them in stackoverflow. But none of them are my answer. Any help, any idea can be very useful. I'm totally stuck. What can I do/check?
I am attempting to upgrade EJBCA.
I attempted to run this on ubuntu 20.04, locally, using wildfly 18. Wildfly 18 results in this error: "CAUSE: Client certificate or OAuth bearer token required."
I have tried this two ways, by importing the keystore, truststore and superadmin from another instance and by creating the CA fresh and using the resulting superadmin.p12.
The home page loads, but the administration gives me the following error:
"AUTHORIZATIONDENIED
CAUSE: Client certificate or OAuth bearer token required. "
I can really use some help with this.
Things I have tried:
(1) I have downloaded superadmin.p12 and imported it into my browsers
(2) I have attempted to upload the superdmin cert:
bin/ejbca.sh ca importcacert ${NAME} ${NAME}.cacert.pem -initauthorization -superadmincn SuperAdmin
This results in The CA certificate is already imported.
(3) Both my keystore.jks and truststore.jks are moved into /ejbca/p12 and /opt/wildfly/standalone/configuration/keystore
(4) I did set "web.reqcertindb=false"
(6) I did try to enable ssl on wildfly 14 (https://docs.bitnami.com/bch/infrastructure/wildfly/administration/enable-ssl-wildfly/)
(7) I have tried a fresh Management_CA as well
The log of /ejbca/adminweb:
"08:20:01,270 ERROR [org.ejbca.ui.web.admin.configuration.EjbcaJSFHelperImpl] (default task-4) org.cesecore.authentication.AuthenticationFailedException: Client certificate or OAuth bearer token required.
08:20:01,279 WARN [org.ejbca.ui.web.admin.configuration.EjbcaWebBeanImpl] (default task-4) Language was not initialized for this session
08:20:01,279 WARN [org.ejbca.ui.web.admin.configuration.EjbcaWebBeanImpl]
I can provide more information if needs be.
Thank you
So, I have it running today. Here is what I learned:
It seems that if you set wildfly up as a service (per instructions) it is going to set up wildfly to run with launch.sh. Launch.sh is going to result in a cipher mistmatch. I needed to run the standalone.sh file instead
Adminweb must be contacted on 8443
if you need to run this thing on domain setup your going to need to post another question
Best,
I have been learning with WebSocket++ and built some of the server examples (Windows 10 Visual Studio 2019). The non-TLS examples work without issues, however, the TLS-enabled examples (echo_server_both.cpp and echo_server_tls.cpp) can't do the handshake. I am very new to web development in general so I know I must be doing something wrong with regards to the certificate and keys.
I am testing the servers with WebSocket King client, an extension of Google Chrome that connects correctly to other websocket servers like wss://echo.websocket.org and to my own localhost when I don't use TLS.
The echo_server_both example comes with a server.pem file, and the echo_server_tls example comes with server.pem and dh.pem. I have used the same files that come with the samples, and I have also tried generating and registering my own .pem files using openSSL. In both cases I get this when the client tries to connect:
[2021-06-29 20:51:21] [error] handle_transport_init received error: sslv3 alert certificate unknown
[2021-06-29 20:51:21] [fail] WebSocket Connection [::1]:63346 - "" - 0 asio.ssl:336151574 sslv3 alert certificate unknown
[2021-06-29 20:51:21] [info] asio async_shutdown error: asio.ssl:336462231 (shutdown while in init)
I discovered these errors after I edited handle_init() in tls.hpp, following a suggestion in another site, to look like this:
void handle_init(init_handler callback,lib::asio::error_code const & ec) {
if (ec) {
//m_ec = socket::make_error_code(socket::error::tls_handshake_failed);
m_ec = ec;
} else {
m_ec = lib::error_code();
}
callback(m_ec);
}
This change let the actual openSSL error to show in the console, otherwise it would show a generic "handshake failed" error.
I know I'm not doing what I should with the certificates, but I have no idea where else to look or what to do next. Can anyone here help please? Should I use the .pem files that come with the examples, or should I generate my own? in case I should generate my own, what would be the openSSL command to do that correctly and how do I tell my PC to recognize these as valid so that the server works?
Found the problem: WebSocket++ will not accept a self-signed certificate (the ones you can create directly in your own PC using OpenSSL or the Windows utilities). There is no way around it. You must have a valid, authority-validated and endorsed certificate. You can get such a certificate for free (valid only for 90 days) from https://zerossl.com/. The site has detailed instructions on how to request, obtain and install a certificate. After getting a valid certificate and installing it on my server, everything worked as it should.
I created a three node etcd cluester, config and start is already OK, but when I check the /var/log/messages, it shows
etcd: rejected connection from "172.17.0.3:43192" (error "tls: first
record does not look like a TLS handshake", ServerName "")
How can I fix it ?
I have checked the health of etcd :
member 48b0dff99d5c867e is healthy: got healthy result from https://172.17.0.9:2379
member 646dab89331aabab is healthy: got healthy result from https://172.17.0.8:2379
member b45603216bfac234 is healthy: got healthy result from https://172.17.0.10:2379
That shows Ok, but when I cat the /var/log/messages, it always shows this error :
Jan 12 20:08:57 master etcd: rejected connection from
"172.17.0.3:43160" (error "tls: first record does not look like a TLS
handshake", ServerName "")
Jan 12 20:08:57 master etcd: rejected
connection from "172.17.0.3:43162" (error "tls: oversized record
received with length 21536", ServerName "")
I got this message for the etcd peer communication when switching from http to https for peer communication. Apparently etcd has persistent peer information that overrides the command line options so it continued to use http for peer communication in spite of the command line options.
In the end, since this was a test cluster, I nuked /var/lib/etcd and the new cli configuration took hold
There is no solution from my side to fully help you with an issue but I've found couple of links that might help you in further investigations. Read them carefully, try solutions and I hope you will resolve the problem.
Github question #9917: check ETCDCTL_API variable, especially make sure --endpoints is configured with https.
Runtime reconfiguration: try to reconfigure you etcd by updating/removing/adding etcs members.
nginx ingress: check your nginx ingress annotations in case you are using nginx
google groups TLS handshake topic: Check this topic, especially comments related to VAULT_ADDR variable. I will copy paste last comment from thread here:
We were able to get everything to work, after understanding the
permission issues.
You asked: "Please confirm if you are seeing server error messages
before initializing Vault" Upon further examination, I did determine
that the errors were not happening before initializing the Vault.
The problem ended up not being related to VAULT_ADDR, and we used the
value: "http://127.0.0.1:8200"
I have the setup operation scripted, and it appears that not
everything was being run at the proper permissions. At first I was
running the scripts using the "sudo" command, which resulted in the
failures. I discovered that the permissions for the certificate key
were restricted and the file could not be accessed by my user. There
may have been other permission issues as well. But once I switched
user to root, and ran the script, everything behaved correctly.
Thanks
I am attempting to install SQL Server Express Edition (64-bit) on my Windows 10 laptop. It is failing, apparently because of this:
2018-06-04 14:55:20.52 spid15s Initializing the FallBack certificate failed with error code: 1, state: 20, error number: 0.
2018-06-04 14:55:20.52 spid15s Unable to initialize SSL encryption because a valid certificate could not be found, and it is not possible to create a self-signed certificate.
2018-06-04 14:55:20.52 spid15s Error: 17182, Severity: 16, State: 1.
2018-06-04 14:55:20.52 spid15s TDSSNIClient initialization failed with error 0x80092004, status code 0x80. Reason: Unable to initialize SSL support. Cannot find object or property.
I do not know how to resolve this; can anyone help me out?
Resolved: for some reason using VPN to log into my employer's network did not allow me to install SQL Server Express. However, from their offices and on the company intranet the problem went away.