I am trying to explore AD integration and was able to succesfully complete the setup as described in AWS blog post, and verified that SSL connection is working fine from "Management box".
Based on my understanding, ldp.exe from Management box is working fine because management box is joined to this AD and certificates are propagated properly.
I have use case where another linux box (which can't be joined to AD) but should use LDAPS over SSL to do some user search. For this to work, I need to export SSL and install it on Linux box. I couldn't quite figure out how to find and export certificates in this example? Are those certificates are available on RootCA (or) SubordinateCA and how to export them? appreciate any help.
I'm assuming you generated the SSL cert in AWS via Amazon Certificate Services (ACS). Although ACS won't allow you to export the private key from ACS, you shouldn't need it. All you need to do is import the public certificate into the certificate trust store that your Linux box is using when it connects to the AD server. I can't tell you how to do that (not sure what the application is), but you should be able to extract the public cert using openssl. You'll point openssl to the ad server, and have it output the public cert.
I'm pretty sure this is the openssl command line that would do that:
openssl s_client -showcerts -connect activedirectory.yourdomain.com:636
You can download the certificate from the ldaps end point and install it as follows.
Install openldap client
sudo yum install -y openldap-clients
• Download and Add Server Certificate to the openldap cert path
openssl s_client -connect <LDAPSURL>:636 -showcerts </dev/null 2>/dev/null | openssl x509 -outform PEM > server.crt
• Configure LDAP Details
Vi /etc/openldap/ldap.conf
BASE dc=corp,dc=example,dc=com
URI ldaps://corp.example.com
TLS_CACERT /etc/openldap/certs/server.crt
Related
I'm trying to configure SSL access to my mosquitto bridrge on Amazon EC2, Ubuntu 18 server. I followed the steps described in mosquitto tls docs and ended up with the following files:
ca.crt
ca.key
ca.srl
client.crt
client.csr
client.key
server.crt
server.csr
server.key
in a temporary directory.
Then I copied three files:
sudo cp ca.crt /etc/mosquitto/ca_certificates/
sudo cp server.key /etc/mosquitto/certs/
sudo cp server.crt /etc/mosquitto/certs/
Then I added the following section to the configuration file:
listener 8883
cafile /etc/mosquitto/ca_certificates/ca.crt
keyfile /etc/mosquitto/certs/server.key
certfile /etc/mosquitto/certs/server.crt
Then I wanted to restart mosquitto:
sudo service mosquitto restart
This doesn't work and responds with
> Job for mosquitto.service failed because the control process exited with error code.
> See "systemctl status mosquitto.service" and "journalctl -xe" for details.
I tried both and there was just information, that the configuration is wrong.
I tried commenting out different lines and the following structure let's the service restart:
listener 8883
cafile /etc/mosquitto/ca_certificates/ca.crt
keyfile /etc/mosquitto/certs/server.key
#certfile /etc/mosquitto/certs/server.crt
Unfortunatelly, the certfile is nessesary for the configuration to work. I checked the example configuration and the docs, and the certfile is a legal and required parameter.
How can I solve this issue?
I'm running Mosquitto on Ubuntu server. I ran also into Mosquitto failing to start after adding SSL certificates and configuration. I got a standalone certificate from Let’s Encrypt by Certbot tool.
Version information:
Ubuntu 18.04.5 LTS,
Mosquitto 2.0.4. (MQTT v5.0/v3.1.1/v3.1 broker) and
Certbot 1.11.0.
In original and failing configuration the mosquitto was configured to use certificates in /etc/letsencrypt... location.
My solution was to move all certificate files from /etc/letsencrypt/archive/ into /etc/mosquitto/ -folder and make the respective certificate file pointers in mosquitto configuration to point to this location.
Most relevant debugging for the problem in the trouble shooting is available in the logfile /var/log/mosquitto/mosquitto.log file.*
Further info about troubleshooting
Playing around with ownerships did not have any effect, in this case. The final configuration with certificates in /etc/mosquitto/certs folder worked regardless if the owner of the files and certificate containing folder was mosquitto or root.
I also tried not using the symbolic links of .../live/... and tested using directly the files in /etc/letsencrypt/archive/... location instead, did not work.
I did not check if some individual file is causing the issue, just moved them all. Tried afterwards to symlink from ..mosquitto/certs one of the files only to note that mosquitto will fail to start. For this server set-up to run, I need to keep the certificate files in ...mosquitto/certs folder".
Changing the certificate/key permissions fixed the issue for me.
E.g.
sudo chmod 744 raspberrypi.crt
sudo chmod 644 raspberrypi.key
As per this forum:-
https://github.com/owntracks/tools/issues/6
I think this is more of a server setup issue?
As the subject says, when I "embed" images to a cfmail, using cfmailparam, if the image is called over https, the email fails. The error I get in mail.log is
javax.mail.MessagingException: IOException while sending message;
nested exception is: java.net.SocketException: Connection reset
Any ideas?
Thx!
Check the {cf_root}/logs/exception.log to see if there is anything more informative.
Sounds like CF isn't liking the SSL certificate. I know some CF versions and using CFHTTP, etc. don't like wildcard or SAN certificates and you have to import those to the keystore.
You have to grab the certificate then use the keytool to import it. This will require a CF restart after.
keytool -import -trustcacerts -keystore ./cacerts -alias myCert -file myCert.cer
Adobe has a write up on how-to: How to import certificates to ColdFusion's truststore
The problem could be because your Java version which is running ColdFusion is not supporting new TLS versions. You can solve this by upgrading Java to 1.8 or later or you can add the following to the JVM config in the ColdFusion Administrator.
-Dhttps.protocols=TLSv1.1,TLSv1.2
Scenario
I have AWS setup for a unifi controller, I've been to access it with https://myserverip:8443, I bypass "This connection is note sucured" and use the controller normally
Now, I need to install and SSL certificate to get the hotspot payment system going.
I have a FQDN with GoDaddy so I created a subdomain unifi.mydomain.com, that points to the elastic IP, I log on with https://unifi.mydomain.com:8443
I bought the SSL certificate from GoDaddy, added the subdomain to that certificate.
I log on my AWS with SSH, generate my csr with the following command
cd /usr/lib/unifi
sudo java -jar lib/ace.jar new_cert unifi.mydomain.dom “My Company Name” City State CC*
Then I do
cd var/lib/unifi
more unifi_certificate.csr.pem
Once I get that I copy and paste it on GoDaddy, download the cert files, go back to AWS copy the files with filezilla to /usr/lib/unifi
Then I run the following command
sudo java -jar lib/ace.jar import_cert unifi_mydomain_com.crt bundlecert.crt
They import correctly, restart unifi service and reboot EC2
When I got to any of the above address I get the following
This site can’t provide a secure connection ERR_SSL_PROTOCOL_ERROR
I've tried different browsers, incognito mode, vpn, etc, I believe it's just a matter of SSL or my server
Check your system.properties which sits in /var/lib/unifi/ open the file with vim or your text editor of choice.
Have a look at your HTTPS options, the important ones are the ciphers and protocols.
The Protocols you need are TLSv1 and potentially SSLv2Hello there should be no other SSL protocols in there.
The Ciphers you ideally want are TLS, so for example TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA
If you are having issues throw them all in, CAUTION! only use this in a demo /test environment.
unifi.https.ciphers=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA
Remember once you have edited the system.properties you need to restart the controller.
sudo service unifi restart
Lots of help on the Unifi page
UniFi - SSL Certificate Error
UniFi - Explaining the config.properties File
UniFi - system.properties File Explanation
I have my Java code deployed on Tomcat in AWS and in Tier 1, I have a load balancer configured with public and private key generated using following commands.
openssl genrsa -out server_privatekey.pem 1024
openssl req -new -key server_privatekey.pem -out server_certificate_csr.pem
openssl x509 -req -days 3650 -in server_certificate_csr.pem -signkey server_privatekey.pem -out server_certificate.pem
Now, the main difficulty I'm facing is as follows:
I have android app which calls this REST API's, now I want to call the API from Android, but that would require me to pass some form of authentication to server. I'm unable to understand what would that be. If anyone could point me to specific resource that would be really helpful.
(Note: I have already posted this question on the AWS forum but there is no reply yet: https://forums.aws.amazon.com/thread.jspa?threadID=64432).
I was able to call the REST API using HTTPS. At client side, I downloaded the certificate and generated the trust store from it using following command
keytool -importcert -keystore secure.ts -storepass 12345678 -file <cert>
and then while calling my REST API using URL command, I used following property.
System.setProperty("javax.net.ssl.trustStore", "<trust store path eg: secure.ts from above command>");
System.setProperty("javax.net.ssl.trustStorePassword", "12345678");
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.