Curl fails with error for MaxScale REST API with TLS - rest

I am trying to make a Java client program use secure REST API calls with "https" protocol to MaxScale proxy of MariaDB. As specified in its document (https://mariadb.com/docs/security/data-in-transit-encryption/enable-tls-maxscale-rest-api/), I created required keys and certificates and added required parameters in the MaxScale configuration file /etc/maxscale.cnf.
[maxscale]
...
admin_ssl_key = /home/.../config/maxscale-server-key.pem
admin_ssl_cert = /home/.../config/maxscale-server-cert.pem
admin_ssl_ca_cert = /home/.../config/maxscale-ca-cert.pem
...
Note that I used "..." in the file names to avoid specifying long paths in this question. Actual configuration file has complete paths.
Then, I tried curl command with a REST API:
curl -i -v -k --user admin:mariadb https://[2401:4900:1f25:6cc1:f32b:cf8:ac92:f447]:8989/v1/servers
and it worked as expected with required JSON o/p on Ubuntu 20.04. Well and good.
Then, I tried to make it work on CentOS 7.9, but it fails with an error as shown in the following o/p from curl command (curl -i -k -v --user admin:mariadb https://192.168.122.1:8989/v1/servers):
* About to connect() to 192.168.122.1 port 8989 (#0)
* Trying 192.168.122.1...
* Connected to 192.168.122.1 (192.168.122.1) port 8989 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* NSS error -5938 (PR_END_OF_FILE_ERROR)
* Encountered end of file
* Closing connection 0
curl: (35) Encountered end of file
One difference I found in the curl command between Ubuntu and CentOS is that the curl of Ubuntu is based on openssl libraries where as the curl on CentOS uses NSS libraries.
I searched for the error "PR_END_OF_FILE_ERROR" on the web. Could get some hint that Ciphers required by client (curl) are not available on the server (But the MaxScale document on TLS for the REST APIs doesn't mention anything about the Ciphers) and hence need to check and add required ciphers on the server (maxscale). However, didn't find any documentation on how to do it. Any help to resolve my problem is well appreciated! Thank you.
Update 1:
MaxScale version in use: 2.3.5
CentOS version: 7.9
Ubuntu version: 20.04

Related

curl request to cluster node port hangs on initializing NSS with certpath

I am attempting to make a local request to the kubernetes cluster that is hosted on my server, the cluster's NodePort is listening at the following address 172.20.120.1:30280. External client in production are required to make requests to 172.20.0.1:8000 (this cannot change), so I am attempting to add a DNAT rule to nat the traffic from:
172.20.0.1:8000 -> 172.20.120.1:30280 (k8s NodePort)
I am able to make curl request to 172.20.120.1:30280 directly and get a successful response back. However, when I make a curl request to 172.20.0.1:8000 it just hangs with the following message:
# curl -vvvk https://172.20.0.1:8000/v1/my-api
* About to connect() to 172.20.0.1 port 8000 (#0)
* Trying 172.20.0.1...
* Connected to 172.20.0.1 (172.20.0.1) port 8000 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
And then it eventually times out with the following error:
...
* NSS error -5961 (PR_CONNECT_RESET_ERROR)
* TCP connection reset by peer
* Closing connection 0
curl: (35) TCP connection reset by peer
When I make a request directly to 172.20.120.1:30280 I don't get that cert error and it works. I get a successful response back.
Does anyone know why I am getting that cert error?

In Minikube Buildroot OS wget: not an http or ftp url

I have Setup minikube in my Machine using Hyper-v in windows 10. All working fine, but when i tried to setup fannel network i execute following commannd.
wget http://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
Oupput:-
Connecting to raw.githubusercontent.com (151.101.192.133:80)
wget: not an http or ftp url: https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
I tried some solution like to install wget and hash -r but not working.
Any idea or suggestion to solve this.
Thank you,
Note that the actual url your wget is trying to connect to is not an http but https url and the output you attached says:
wget: not an http or ftp url
which is true as https is neither http nor ftp url. It looks like your wget version supports only two mentioned protocols.
You can easily check it by issuing following commands:
wget -V | grep https
and
wget -V | grep ssl
I tried to reproduce it on a system possibly similar to the one you're using. For this purpose I created a buildroot Pod from advancedclimatesystems/docker-buildroot image:
kubectl run --generator=run-pod/v1 buildroot --image=advancedclimatesystems/docker-buildroot --command sleep 3600
and I attached to it by:
kubectl exec -ti buildroot /bin/sh
Once there, I tested out your wget command and it was successful. It's output in my system looks like this (note the 301 redirection to https url):
root#buildroot:~/buildroot# wget http://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
--2019-12-31 16:04:27-- http://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.0.133, 151.101.64.133, 151.101.128.133, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.0.133|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml [following]
--2019-12-31 16:04:27-- https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.0.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 14416 (14K) [text/plain]
Saving to: 'kube-flannel.yml'
kube-flannel.yml 100%[=====================================================================================================================>] 14.08K --.-KB/s in 0s
2019-12-31 16:04:27 (53.3 MB/s) - 'kube-flannel.yml' saved [14416/14416]
As you can see it has built-in ssl and https support:
root#buildroot:~/buildroot# wget -V | grep ssl
+ntlm +opie +psl +ssl/openssl
-Wl,-z,relro -Wl,-z,now -lpcre -luuid -lidn2 -lssl -lcrypto -lpsl
ftp-opie.o openssl.o http-ntlm.o ../lib/libgnu.a
root#buildroot:~/buildroot# wget -V | grep https
-cares +digest -gpgme +https +ipv6 +iri +large-file -metalink +nls

ADMU0509I: The Application Server "server1" cannot be reached. It appears to be stopped

I have setup a WebSphere Application Server on my RHEL 7 virtual machine. When I start the server, it starts fine and I can access the admin console but when I try to stop or get the status of the server using the script
sh stopServer.sh -server1 / sh serverStatus.sh server1
It gives the following message,
ADMU0509I: The Application Server "server1" cannot be reached. It appears to be stopped.
My wsadmin scripts are not working, when I run the script
sh wsadmin.sh -user wasadmin -password Password
I get the following error
WASX7023E: Error creating "SOAP" connection to host "localhost"; exception information: com.ibm.websphere.management.exception.ConnectorNotA
vailableException: [SOAPException: faultCode=SOAP-ENV:Protocol; msg=; targetException=java.net.MalformedURLException]
WASX7213I: This scripting client is not connected to a server process; please refer to the log file /opt/IBM\WebSphere/AppServer
/profiles/AppSrv01/logs/wsadmin.traceout for additional information.
I can access the console on the browser without any issue.
To expand on this more specifically. The file ssl.client.props looks like this typically around the com.ibm.ssl.protocol property:
$ grep -i tls -C 2 /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/properties/ssl.client.props
#-------------------------------------------------------------------------
com.ibm.ssl.alias=DefaultSSLSettings
com.ibm.ssl.protocol=SSL_TLS
com.ibm.ssl.securityLevel=HIGH
com.ibm.ssl.trustManager=IbmPKIX
--
#-------------------------------------------------------------------------
#com.ibm.ssl.alias=AnotherSSLSettings
#com.ibm.ssl.protocol=SSL_TLS
#com.ibm.ssl.securityLevel=HIGH
#com.ibm.ssl.trustManager=IbmX509
This property can take a number of values:
This property is the SSL handshake protocol that is used for this SSL
configuration. This property attempts Transport Layer Security (TLS)
first, but accepts any remote handshake protocol, including SSLv3 and
TLSv1. Valid values for this property include SSL_TLS, SSL, SSLv2
(client side only), SSLv3, TLS, TLSv1, SSL_TLSv2, TLSv1.1, and
TLSv1.2.
These values are described in this table:
References
ssl.client.props client configuration file
Appendix A: Protocols and Cipher Suites
For me this problem came when the security level of the WAS was not consistent.
In the IBM console, it was set to TLSv1.2 and in ssl.client.props file it was set to SSL_TLS. Once they were changed to the same value my console could connect to WAS.

wget proxy authentication error

I get the following error when trying to connect to a http URL through a proxy using wget
the error:
wget "http://pro.fastmarkets.com/feeds/default.aspx?usr=anzbank&pwd=587345bv98735vb2b56&feed=physicals-csv" -O /tmp/test.csv
**wget: Error in /home/acdbaqa/.wgetrc at line 3.**
--06:04:15-- http://pro.fastmarkets.com/feeds/default.aspx?usr=anzbank&pwd=587345bv98735vb2b56&feed=physicals-csv
=> `/tmp/test.csv'
Connecting to 59.154.134.109:80... connected.
Proxy request sent, awaiting response... 407 Proxy Authentication Required
06:04:15 ERROR 407: Proxy Authentication Required.
my .wgetrc file contents:
http_proxy=59.154.134.109:80
proxy_user=ACPROXYPROD
proxy_password=test
#password='Ev*luti*n0456789'
#proxy-password='Ev*luti*n0456789'
ftp_proxy=204.2.23.10:80
line 3 is the password. am i missing anything here? not sure why it says error at line 3
Τhis was solved by changing the .wgetrc file with the below parameters
proxy-user=ACPROXYPROD
proxy-passwd=test1245
it is NOT proxy_user and proxy_password.
You are using an older wget release where the password setting used the following syntax (note the missing "or" in password):
proxy_passwd=test

Unable to configure nginx as mail proxy

I need to use nginx as a mail proxy. I am completely new to nginx and need some help with the configuration.
Here is what I did:
First I built a service that mocks the authentication services described here: http://wiki.nginx.org/NginxMailCoreModule. For example,
curl -v -H "Host:auth.server.hostname" -H "Auth-Method:plain" -H "Auth-User:user" -H "Auth-pass:123" -H "Auth-Protocol:imap" -H "Auth-Login-Attempt:1" -H "Client-IP: 192.168.1.1" http://localhost:8080/authorize
returns the following response header:
< HTTP/1.1 200 OK
< Content-Type: text/html;charset=ISO-8859-1
< Auth-Status: OK
< Auth-Server: 192.168.1.10
< Auth-Port: 110
Second I installed nginx on my mac after installing macports:
$ sudo port -d selfupdate
$ sudo port install nginx
Third I created an nginx.conf with the following:
worker_processes 1;
error_log /var/log/nginx/error.log info;
mail {
server_name <my mail server here>;
auth_http http://localhost:8080/authorize;
pop3_auth plain apop cram-md5;
pop3_capabilities "LAST" "TOP" "USER" "PIPELINING" "UIDL";
xclient off;
server {
listen 110;
protocol pop3;
proxy on;
proxy_pass_error_message on;
}
}
Here is what I got running nginx:
$ nginx -V
nginx version: nginx/1.2.4
configure arguments: --prefix=/opt/local --with-cc-opt='-I/opt/local/include -O2' --with-ld-opt=-L/opt/local/lib --conf-path=/opt/local/etc/nginx/nginx.conf --error-log-path=/opt/local/var/log/nginx/error.log --http-log-path=/opt/local/var/log/nginx/access.log --pid-path=/opt/local/var/run/nginx/nginx.pid --lock-path=/opt/local/var/run/nginx/nginx.lock --http-client-body-temp-path=/opt/local/var/run/nginx/client_body_temp --http-proxy-temp-path=/opt/local/var/run/nginx/proxy_temp --http-fastcgi-temp-path=/opt/local/var/run/nginx/fastcgi_temp --http-uwsgi-temp-path=/opt/local/var/run/nginx/uwsgi_temp --with-ipv6
$ nginx
nginx: [emerg] unknown directive "mail" in /opt/local/etc/nginx/nginx.conf:6
The only mention of that error on the web brings up a discussion in Russian...
My questions:
Why am I getting this unknow directive?
Does my config look correct at first sight or am I missing some key component for the mail proxy to work using the authentication approach described here: http://wiki.nginx.org/NginxMailCoreModule?
I got the mail proxy working so I will answer my own questions for future reference:
nginx doesn't install support for mail by default
The following is needed for nginx to process the mail directive:
$ sudo port edit nginx
==> add --with-mail at the end of the config parameters
Then (re)install nginx
In the config I included, I was missing the events:
events {
worker_connections 1024;
}
An important clarification that got me stuck for a while: the authentication service (specified with auth_http) needs to return the mail server expressed as an IP address, not a host name.
Obviously for nginx to proxy on both inbound and outbound traffic, the smtp listener needs to be added. Similar approach as with the pop3 configuration. In my case, I used port 2525, so I had
server {
listen 2525;
protocol smtp;
}