how to get ssl certificate for ldap/Active directory - ssl

am new to LDAP / Active Directory environment.
am trying to connect with LDAP / Active Directory using SSL support.
to connect LDAP/Active Directory, SSL certificate is required to establish the connection.
I have been googling, and most of the result is to "create certificate using Microsoft CA (certificate authority)". Is this is only way to generate certificate for LDAP/Active Directory?
How can i get SSL Certificate for LDAP / Active Directory?
Is there any other way to get the SSL Certificate for LDAP/Active Directory?

The OpenSSL tool can be used to:
generate a new self-signed certificate
generate a certificate request
retrieve an existing certificate from an LDAP server using LDAPS (but not StartTLS as of OpenSSL 0.9.8)
OpenSSL is available via the console on Mac OS and most Linux distributions.
You can get OpenSSL for Windows here:
OpenSSL Distributions
The Mac Keychain Access application can also be used to generate certificates.

LDAP client code that requires a secure connection should connect to the port upon which the directory server listens for SSL connections, or connect to the port upon which the directory server listens for unsecure connections and promote the connection security using the StartTLS extended operation. The certificate to which you refer is the certificate used by the directory server.

Related

Certbot SSL keys file names

I am setting up SSL for an IOT device that uses MQTT protocol acting as a client and connecting to a broker server. The server is using Certbot for SSL keys and registration. I configure the IOT device using AT commands and in the AT command I need the cacert, clientcert, and clientkey shown in the picture below. But I am wondering what are the names of these files on my server which is Ubuntu 20?
My best guess is one of the files below:
root#broker1:/etc/letsencrypt/keys# ls
0000_key-certbot.pem 0001_key-certbot.pem 0002_key-certbot.pem 0003_key-certbot.pem
or
root#broker1:/etc/letsencrypt/live/mydnsaddress# ls
README cert.pem chain.pem fullchain.pem privkey.pem
Unless you are using SSL Client authentication the only files you need on the client will be /etc/letsencrypt/live/<hostanme>/fullchain.pem
If you are using SSL Client authentication then you will need a certificate and private key specific to that client and that will not be issued by LetsEncrypt but by a private CA.

Unable to validate SMTP certificate on Ubuntu, but works for Windows

I'm trying to send email using MailKit through provider's SMTP server using valid Let's Encrypt Authority X3 certificate. On Windows everything works great, but when sending from Ubuntu I get certificate error:
MailKit.Security.SslHandshakeException: An error occurred while attempting to establish an SSL or TLS connection.
One possibility is that you are trying to connect to a port which does not support SSL/TLS.
The other possibility is that the SSL certificate presented by the server is not trusted by the system for one or more of the following reasons:
The server is using a self-signed certificate which cannot be verified.
The local system is missing a Root or Intermediate certificate needed to verify the server's certificate. (I believe this is my problem?)
The certificate presented by the server is expired or invalid.
When I dig deeper into X509Chain status it says
RevocationStatusUnknown unable to get certificate CRL
Up until now I've been ignoring this error, but I'd rather have the underlying problem fixed and I don't know what exactly I'm missing. Thanks.
If you are running your .NET application on Mono, there's a Mono FAQ that explains how to import root certificates into your certificate store: https://www.mono-project.com/docs/faq/security/
If you are using .NET Core CLR, you might find this answer helpful: Trusted Root Certificates in DotNet Core on Linux (RHEL 7.1)

Installing an SSL Certificate on Google Apps Script

I want/need to install an TLS (1.2 or higher) Certificate (remember to SSL).
I have probably the Certificate (apt12345678.p12).
How could i copy the Certificate in my Apps Script?
Docu says: "The connection to the authorization server is established using Mutual SSL."

TLS certificate installation in ejabberd for STARTTLS negotiation

I read that ejabberd recommends to use STARTTLS negotiation for secure connection between communicating entities. When I install ejabberd, by default it comes with a TLS certificate.
Then, why do I need to buy a certificate to install? what is the purpose of buying a new certificate from Certificate Authoririty since we have a default certificate?
When I deploy ejabberd on the machine, how the default certificate will be used for my domain? How the default certificate will be verified by client?
You can use ejabberd with SSL / STARTTLS with the provided TLS certificate. However, that certificate is only a self-signed certificate. It means that:
You will still be able to encrypt the traffic between the client and the server.
You client will not be able to check that the server is the domain it pretends to be. To be able to know that the certificate can be trusted the client need to refer to a trust authority in some way.
In the second case, it means that if an intermediate network device (i.e Wifi access point) tries to impersonate your server, it can present any self-signed certificate to the user, pretending to be your domain.
So, you can definitely use self-signed certificate to encrypt traffic, but to protect your users against man-in-the-middle type of attacks, you need to find a way to let the client now it can trust the certificate.
This can be done either by buying a certificate from a trusted authority (that will certify your certificate domain) or by making the client support a list of well defined certificates. This is called certificates pinning, however it requires to build the list of acceptable certificates into your client, which may not be possible.
It may be fine in your case, so buying a certificate is not mandatory.
However, not use the default ejabberd self-signed certificate, even if you plan using a self-signed certificate. The certificate provided with ejabberd will not match your own domain. You should at least generate your own self signed certificate that match your actual XMPP domain: How to create a self-signed certificate with openssl?
The client will verify whether the certificate is issued for the domain name of the Jabber ID (JID), the part behind the '#'. (There are other options, but they are incompatible with the policies enforced by the browser vendors against CAs and therefore not practical.)
Unless you already have a business relationship to a certificate authority (CA), I would recommend anyone to use Let's Encrypt and stay away from self-signed certificates.
Some instructions to automate this and be nice to the Let's Encrypt servers can be found here and the linked wiki pages.
Summary (assuming you are running Ubuntu 16.04 LTS, want to run it on the domain example.org and only use the certificate for ejabberd):
Create /usr/local/sbin/auto-renew-letsencrypt with the following content:
#!/bin/bash
# Renew all Let's Encrypt certificates which are due for renewal
t=`mktemp`
# Try to be quiet unless an error is returned
letsencrypt renew > $t || cat $t
# Hooks are not yet supported by `letsencrypt` shipping with Ubuntu 16.04 LTE
# Crudely emulate --renew-hook; breaks if diagnostic messages change
if grep -q "The following certs have been renewed" $t; then
cat /etc/letsencrypt/live/example.org/{privkey,fullchain}.pem > /etc/ejabberd/ejabberd.pem
service ejabberd reload
fi
rm $t
Run the following commands to create and activate the certificate and the automatic renewal
apt install letsencrypt
letsencrypt certonly --standalone --domain example.org
cat /etc/letsencrypt/live/example.org/{privkey,fullchain}.pem > /etc/ejabberd/ejabberd.pem
chown ejabberd:ejabberd /etc/ejabberd/ejabberd.pem
chmod 640 /etc/ejabberd/ejabberd.pem
chmod 755 /usr/local/sbin/auto-renew-letsencrypt
echo $(($RANDOM % 60)) $((RANDOM % 6)) "* * * root /usr/local/sbin/auto-renew-letsencrypt" > /etc/cron.d/auto-renew-letsencrypt

Websphere application server not supporting Deutsche Telekom Root certificate

We are consuming xml from different datasources. Some are http and some are https. HTTPS with Verisign certificates are working without any issues. However, URLs with Deutsche Telekom Root certificate is not working. The web sphere application server is having the default root certificate which was generated while creating a WAS profile. Do I have to add any other special certificate to make Deutsche Telekom Root certificate work ? Any kind of help is much appreciated.
I don't think I know enough about your setup yet. So by default WebSphere creates it's own root certificate, nothing about it would trust a Verisign certificate. So I wonder about what you are using to make the https connection? It could be something that manages to bypass the WebSphere socket factories and you are actually using the JRE's default, and the cacerts file for trust. Verisign certs are in the cacerts file there are no Deutsche Telekom as far as I can tell.
Or was a Verisign certificate added to your WebSphere truststore at some time?
Typically you have establish trust to make WebSphere trust another server. Retrieving a certificate from a port is a good way to do that.
Alaine
Please, post the WAS version you use.
The reason you cannot setup the connection to ssl port is that WAS doesn't trust to the ssl certificate of the remote host.
You have to add the whole certificate chain of the remote host to the WAS truststore.
You can find the example of how to add the certificate by following link https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=8&cad=rja&uact=8&ved=0CE0QFjAHahUKEwiRy4zsztzGAhXCfHIKHVq-BfM&url=http%3A%2F%2Fwww.webspheretools.com%2Fsites%2Fwebspheretools.nsf%2Fdocs%2FBasic%2520SSL%2520terminalogy%2520and%2520Tips%2520for%2520WebSphere%2520Application%2520Server.Default%2520passwords%2520for%2520SSL%2520keyfile%2520and%2520Truststore.&ei=DwymVdGHDcL5yQPa_JaYDw&usg=AFQjCNE42W06AILWb99iYWiUp7EcbT92iw&sig2=KKYyvAsFET1Ae0fOLSl8zA&bvm=bv.97949915,d.bGQ