When I use the recommended rdesktop to connect to Windows EC2 host I see from Archlinux:
$ rdesktop 54.254.180.73
ATTENTION! The server uses and invalid security certificate which can not be trusted for
the following identified reasons(s);
1. Certificate issuer is not trusted by this system.
Issuer: CN=EC2AMAZ-I5MV8JK
Review the following certificate info before you trust it to be added as an exception.
If you do not trust the certificate the connection atempt will be aborted:
Subject: CN=EC2AMAZ-I5MV8JK
Issuer: CN=EC2AMAZ-I5MV8JK
Valid From: Thu Mar 5 16:06:01 2020
To: Fri Sep 4 16:06:01 2020
Certificate fingerprints:
sha1: 98f1e92f9b9a3b57f4b2a23177f1bbe1a9afeb2c
sha256: 8e9f1a2e5497c972b56b8300f6e2ec3f59c8903103984cb5456a237c9a7b2d45
Do you trust this certificate (yes/no)? yes
Failed to initialize NLA, do you have correct Kerberos TGT initialized ?
Failed to connect, CredSSP required by server (check if server has disabled old TLS versions, if yes use -V option).
I'm not sure where to go from here. Especially when rdesktop doesn't appear maintained.
Any tips to connect to a Windows host?
Instead of rdesktop, the FreeRDP: A Remote Desktop Protocol Implementation seems to better accommodate this CredSSP required by server issue.
xfreerdp /u:"Administrator" /v:ec2-3-1-49-118.ap-southeast-1.compute.amazonaws.com
Related
I have postgreSQL installed on both Windows and Linux Ubuntu VMs.
(1) Is SSL connection possible for PostgreSQL with basic authentication (Username/password authentication) ?
If possible , should the certificates be installed on the client machine , which invokes PostgreSQL
(2) Is pg_hba.conf file present on the PostgreSQL server or client machine ?
Please help
SSL Connection is possible with basic authentication..it is called MD5 authentication.. in Postgres.conf, we have to set ssl=on and in pg_hba.conf we should use hostssl Instead of host...we can also use client certificate option
pg_hba.conf file is present on server where Postgres is installed
I'm trying to get Ejabberd to work with letsencrypt certificates on centos7.
I keep getting errors about the certificates not being signed by a known CA.
I have created the certificates by certbot, and I joined the privkey and fullchain files to single file.
All c2s connections work fine, but s2s connections don't.
When starting Ejabberd I see the following relevant log entries:
[warning] <0.606.0>#ejabberd_pkix:check_ca_dir:386 CA directory /etc/ssl/certs doesn't contain hashed certificate files; configuring 'ca_path' option might help
[warning] <0.606.0>#ejabberd_pkix:mk_cert_state:240 certificate from /opt/ejabberd/conf/xxxx.pem is invalid: certificate is signed by unknown CA
Connections to for example draugr.de generate the following entries:
[info] <0.793.0>#ejabberd_s2s_in:handle_auth_failure:206 (tls|<0.792.0>) Failed inbound s2s EXTERNAL authentication draugr.de -> XXXXX.net (::FFFF:89.163.212.45): unable to get local issuer certificate
I hope someone can help me out, thanks!
[EDIT 2020 may]
It looks like ejabberd now has automatic acme support (meaning it can request the certificate on its own from letsencrypt). So what you read below is obsolete.
As of 2018 november,
Merely installing letsencrypt using certbot is enough click here to see how. Ejabberd uses the provided certificates.
Note that you may need to register multiple subdomains for some strict jabber clients to work properly.
conference.yourjabberdomain.com
pubsub.yourjabberdomain.com
upload.yourjabberdomain.com
yourjabberdomain.com
or install a wildcard certificate from letsencrypt
sudo certbot certonly --server https://acme-v02.api.letsencrypt.org/directory --manual --preferred-challenges dns -d *.yourjabberdomain.com
I think there is a rule in the ejabberd config file ejabberd.yml that allows this to happen
certfiles:
- "/etc/letsencrypt/live/*/*.pem"
I was able to solve it myself finally but i am out of office the next few days and can't get you the exact configuration to solve it.
But if I recall correctly I downloaded the CA bundle here https://curl.haxx.se/docs/caextract.html and there was some configuration parameter for ejabberd to use this CA bundle in stead of the default one.
Hope it helps you.
If it is working for c2s and not working for s2s then it looks like the s2s block in configuration file is not updated with certfile. I believe you have something like this for c2s:
port: 5222
ip: "::"
module: ejabberd_c2s
starttls: true
certfile: 'CERTFILE'
protocol_options: 'TLSOPTS'
Similarly your s2s block should have:
port: 5269
ip: "::"
module: ejabberd_s2s_in
starttls: true
certfile: 'CERTFILE'
protocol_options: 'TLSOPTS'
max_stanza_size: 131072
shaper: s2s_shaper
I'm installing a modern GoCD (16.7) on an Ubuntu machine. openjdk-8 (jre and jdk). The agents (on localhost) fail to connect to the server:
[Sat Jul 30 05:58:47 UTC 2016] Starting Go Agent Bootstrapper with command:
/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
-jar /usr/share/go-agent3/agent-bootstrapper.jar
-serverUrl https://127.0.0.1:8154/go/
...
java.lang.Exception: Couldn't access Go Server with base url:
https://127.0.0.1:8154/go/admin/agent-launcher.jar:
java.net.SocketException: Broken pipe
at com.thoughtworks.go.agent.launcher.ServerCall.invoke(ServerCall.java:78)
and
2016-07-30 06:00:48,790 [main ] ERROR go.agent.launcher.ServerBinaryDownloader:118
- Couldn't update admin/agent-launcher.jar. Sleeping for 1m.
Error: java.lang.Exception: Couldn't access Go Server with base url:
https://127.0.0.1:8154/go/admin/agent-launcher.jar:
java.net.SocketException: Broken pipe
(I manually wrapped those lines for readability)
The server is actually accessible. For instance:
$ curl --silent --insecure https://127.0.0.1:8154/go/ | head -2
<!-- *************************GO-LICENSE-START******************************
* Copyright 2014 ThoughtWorks, Inc.
Yes, I'm using --insecure, but gocd ships with a self-signed cert. It's standard practice. Some of the things I've seen said "oh, you are blocking your port" but this is to localhost.
Are your GOCD server and agent using identical versions of Java? We have found they must be the same because the certificates have to match. See chatter
I realise that the firewall should not block traffic moving between terminal sessions on the same server, but I have included detail of my firewall here as it might be related somehow. The crux of this problem is "What linux/AWS setting could be stopping me from communicating on a port on the same instance"
I have an amazon instance (not build by me) running Debian. I am trying to get an email relay running, but that question is in another post. For starters, I just want to make sure that a port is open. The way I do this on other servers is, I make sure the firewall is not blocking the port, and then get netcat to listen on that port. So, for my instance I went to AWS security management and opened port 2525 both UDP and TCP
nothing is blocked outbound
and checked the local firewall
root#lamp # iptables-save
# Generated by iptables-save v1.4.14 on Sun Feb 28 10:36:57 2016
*nat
:PREROUTING ACCEPT [727933:41936189]
:INPUT ACCEPT [727933:41936189]
:OUTPUT ACCEPT [4341889:262878645]
:POSTROUTING ACCEPT [4341889:262878645]
COMMIT
# Completed on Sun Feb 28 10:36:57 2016
Then I ran netcat to listen on port 2525
root#lamp # nc -l 2525
logged on via a different terminal session to the same server
root#lamp /home/www# nc localhost 2525
localhost [127.0.0.1] 2525 (?) : Connection refused
root#lamp /home/www# netstat -anp | grep 2525
root#lamp /home/www# telnet localhost 2525
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
I try this on my ubuntu laptop or on my rackspace instance, the nc command should get me a kind of chat session which I terminate with a CTRL^D.
I am not too familiar with the way Amazon do things, so I guess I am missing some AWS web interface, but what confuses me is I would expect all traffic to be free to travel between different sessions on the same localhost. Any light that could be shed on allowing traffic on this port would be appreciated.
AWS Security Groups wouldn't be getting involved here in terms of opening + connecting to the server locally.
It's only relevant when trying to connect to and from other servers.
I suspect your issue is a Linux configuration issue, but of what flavour I do not know.
I'm having a major pain getting my new SSL certificate to work with GlassFish 3.1.2.2. My current SSL certificate is due to expire soon, so I ordered a renewal at GlobalSign.
With my current SSL certificate I get following response (this is done through SoapUI for testing purposes):
HTTP/1.1 200 OK
X-Powered-By: Servlet/3.0 JSP/2.2 (Oracle GlassFish Server 3.1.2.2 Java/Oracle Corporation/1.7)
Server: Oracle GlassFish Server 3.1.2.2
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 01:00:00 CET
Content-Type: application/xml
Transfer-Encoding: chunked
Date: Mon, 11 Jan 2016 13:38:32 GMT
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>..(xmlresponse)..</xml>
However, with the new SSL certificate active, I get following message:
SoapUI:
Error getting response; javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake.
Browser:
This page can’t be displayed
Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to again. If this error persists, contact your site administrator.
The only thing I changed in the config of glassfish is the following:
Configurations > server-config > HTTP Service > Http Listeners > http-listener-2 > SSL tab
The Certificate NickName field from my old alias (mydomain) to my new alias (mydomain.net), which matches the alias of my private key in the keystore
The Key Store field value (file name) from the old keystore (server.keystore) to my new keystore (ssl_mydomain_net.jks)
Both new and old keystores are inside the C:\glassfish3\glassfish\domains\mydomain\config folder.
Old SSL settings:
New SSL settings:
I already had contact with GlobalSign support and we verified that the keystore is correctly generated.
When I run keytool -list -keystore ssl_mydomain_net.jks I get following output which should be correct:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 3 entries
root, Jan 8, 2016, trustedCertEntry,
Certificate fingerprint (SHA1): <...>
intermediate, Jan 8, 2016, trustedCertEntry,
Certificate fingerprint (SHA1): <...>
<mydomain>.net, Jan 8, 2016, PrivateKeyEntry,
Certificate fingerprint (SHA1): <...>
As far as I concluded, it has something to do with Glassfish. Does anyone have any idea because I'm out of options here...
Update January 13th, 2016
I upgraded from Glassfish 3.1.2.2 to Payara 4.1 (which is basicly Glassfish 4.1). I created a new fresh domain and noticed that by default the following jks files were in the mydomain/config folder:
cacerts.jks
keystore.jks
I added my own jks (ssl_mydomain_net.jks) to this folder and adjusted the settings for the http-listener-2 as above in the new SSL image. This gave me the same result as mentioned at the start of this post.
What am I missing? Do I have to adjust something to the default jks files? Do I have to create a csr from the keystore.jks instead of my own made keystore?
What do I need?
A GlobalSign SSL Certificate
Windows server with IIS installed
Payara instance
Getting your certificate from GlobalSign
Order or renew your SSL certificate at the GlobalSign website. During the process, choose the option Order with AutoCSR. The password of the new certificate will exist out of a password that you have to give during the creating process added by an extra string created by GlobalSign. Please remember this password as you will need it in the next phases.
Once your order is complete, you should be receive a PFX file. Copy this file to the Windows server where IIS is running.
Setting/Changing the master password for Payara
The password of the certificate which will contain your private and public key will have to match the master password of Payara (This can be freely chosen, this is NOT the password of your certification request at GlobalSign). You can change the master password by running following command:
asadmin change-master-password –savemasterpassword=true mydomain
Installing the certificate
Right click the PFX file and choose Install PFX
At the welcome screen, click Next
At the File to import screen, click Next as the PFX file location should be in there by default.
Enter the password. Remember, this is the password you gave up at the certificate creation extended by the string GlobalSign created.
Select the Mark this key as exportable. option.
Select the Include all extended properties. option.
Click Next
In the Certificate Store window, choose the Place all certificates in the following store option.
Click the Browse button.
Choose the Personal store.
Click OK
Click Next
Click Finish
Export the public and private key
Open the Microsoft Management Console (Start > Run > mmc > OK)
Click File > Add/Remove Snap-ins
Choose Certificates under the Available snap-ins list
Click the Add button
In the next window, choose the My user account option
Click Finish
Click OK
In the management console, expand Certificates - Current User > Personal > Certificates. If all want correct, you should see 3 certificates: GlobalSign Domain Validation CA, GlobalSign Root CA and mydomain.net.
Right click the mydomain.net entry
Choose All Tasks > Export...
In the welcome screen, press Next
Choose Yes, export the private key option
Click Next
In the Export File Format window, Choose Personal Information Exchange - PKCS # 12 (.PFX) and select the Include all certificates in the certification path if possible and Export all extended properties options.
Click Next
In the Password window, enter your Payara master password (this has to match!)
Click Next
Select the location were you want to put the export PFX file (e.g. mydomain.pfx) and click Next.
Click Finish
Getting the alias name
Run the following command to find out the generated alias name:
keytool -list -storetype pkcs12 -keystore mydomain.pfx
You will have to enter your keystore password, which should be the same as your Payara master password (see step 29).
When this command runs succesful, you should see your alias on the first line of the export. This looks like a long string of text (e.g. {fa2ebfd3-z11b-492d-2c73-f5z199732p2k}) followed by the date. Copy this string of text as we will need it later.
Adding the certificate to Payara
These are the two important steps that I was missing. We have to add the certificate to the cacerts.jks and keystore.jks who is located in the payara_install_folder/glassfish/domains/mydomain/config. This can be done by following two commands:
keytool -importkeystore -deststorepass <payara masterpassword> \
-destkeypass <payara masterpassword> -destkeystore cacerts.jks \
-srckeystore mydomain.pfx -srcstoretype PKCS12 \
-srcstorepass <payara masterpassword> \
-alias mydomain_alias_name //in our example this would be {fa2ebfd3-z11b-492d-2c73-f5z199732p2k}
keytool -importkeystore -deststorepass <payara masterpassword> \
-destkeypass <payara masterpassword> -destkeystore keystore.jks \
-srckeystore mydomain.pfx -srcstoretype PKCS12 \
-srcstorepass <payara masterpassword> \
-alias mydomain_alias_name //in our example this would be {fa2ebfd3-z11b-492d-2c73-f5z199732p2k}
Setting http-listener in Payara
Open your Payara admin console (normally this would be http://localhost:4848)
Go to Configurations > server-config > HTTP Service > HTTP Listeners > http-listener-2
Enable Security on the General tab
On the SSL tab, Enable SSL3 and TLS
In the Certificate NickName enter mydomain_alias_name (in our case {fa2ebfd3-z11b-492d-2c73-f5z199732p2k})
In the Key Store field, enter keystore.jks
Press the Save button
Restart your domain
Test if it works! :)
Thanks a lot to GlobalSign support and Max Lam who created a guide How To Install Comodo SSL Certificate Chain On Payara / Glassfish 4.x. Combining all this knowledge made me come up with the solution.
There is probably a way to replace the Installing the certificate and Export the public and private key part by running keytool commands. But as I'm not a 100% familiar with certificates, I left those out. If someone can tell me the right commands, let me know and I'll update the answer.
Add your new certificate to the truststore of the JVM that your server is using. If you take a look to your output when list the certificates of your keystore, you could see that your new certificate is not a trustedCertEntry.