MICROSOFT

The configurations were tested on the following environment, for others check working path, and available tested release.
See our best practices to install clients and keep them up to date.

Because JXPLORER is a JAVA application the GUI (Graphical user Interface) is very similar on the different implementation platforms.

Windows XP Sp 2

JAVA (tm) SE Runtime environment 6 update 1
JXv3.2

Window 2000 Sp 4

JAVA (tm) SE Runtime environment 6 update 1
JXv3.2

Enabling SASL-LDAPS queries

You need to attach certificates and related stuff to the JXPLORER application. That is you have to perform the following steps:

1. Obtain a user certificate (or jump to certFormat if you already have one)
   • Choose between self signed certificates or certificates from an external CA chooseCert
   • Be prepared to to fill certificate application (Check fillingDN TAB)
   • Prepare a PKCS10 certificate request or go to an online certification enrollment
     • You may use IBM tool KEYMAN as certificates manager or CA web form
     • You may use LINUX / openssl command line opensslCli
     • Check that you request a certificate for client authentication purposes certsPurpose
   • Retrieve your signed certificate certRetrieve
     • Verify your certificate purpose certVerify
     • check the content of your signed certificate certCheck
   • Get your associated certificate key keyRetrieve
2. Retrieve the Certification Authority certificate(s)CAcertsRetrieve
3. Check if your personal keyset is in JKS or PKCS12 format certFormat
4. Install JXPLORER Download
5. Update your JXPLORER certificates repositories (Java KeyStore and PKCS12) jxplorerSECURITY
   • Set the Java KeyStore of trusted Certification authorities publicJKS
   • Set your personal keyset personalCERT
   • Check your certificates configuration keystoreCheck
6. Set JXPLORER connection properties to your LDAPS server connectLDAPS
7. Securely transmit your certificate to your LDAPS server administrator

---

Return to top of page topJXPLORER

Choose between self signed certificates or certificates from an external CA

In general you should choose self signed certificates for testing purposes and certificates from an external CA for production, unless you have a fully operational PKI (Public key Infrastructure). Using self signed certificate in a production environment may be dangerous, particularly because the revocation process will not be reliable. Appropriate security should carefully be managed for self signed certificates. If your root CA is compromised all your authentication process relying on certificates will be compromised.

If you don't want to use commercial certification authorities use an open source package for handling a PKI like ejbca, or use an open source identity provider like openosi.org

---

Return to top of page topJXPLORER

Use openssl to generate a certificate request MyName.csr

The outputs will be

1. a private key, without with RSA coding and 1024 bit coding key named MyName.key
2. a PKCS10 format certificate signing request named MyName.csr

Option You may want to first generate the private key, then the signing request [root@example-host conf.d]# openssl genrsa -out MyName.key 1024 [root@example-host conf.d]# openssl req -new -key MyName.key -out MyName.csr You may also want a shorter key length (i.e: 512 instead of 1024), or longer (i.e: 2048 instead of 1024).

To verify the content of your signing certificate request (CSR)

For more detailed information hit openssl request reference

---

Return to top of page topJXPLORER

Verify your certificate purpose: client authentication

• If you use an on line submission, choose the appropriate submission form
• If you generate your request use the appropriate template
  • If you use openssl check /etc/pki/tls/openssl.cnf for
    • nsCertType= client
    • keyUsage= digitalSignature,keyEncipherment
    • default is to have nothing which allows all usage for your certificate, avoid this!

Key usage should be:

• Digital signature
• Key encipherment
• Non-repudiation, optional for JXPLORER but recommended
• Data Encipherment, optional for JXPLORER but recommended

Extended key usage should be (see RFC 3280):

• client auth (include OID=1.3.6.1.5.5.7.3.2)
• E-mail protection (include OID=1.3.6.1.5.5.7.3.4), optional for JXPLORER but recommended

---

Return to top of page topJXPLORER

Retrieve your signed certificate

You can retrieve your certificate from an on line certification authority or from an LDAP directory. In the later case you could only retrieve the public key, providing the private key was generated locally.

• For an on line retrieval go the appropriate URL of the certification authority
• For an LDAP retrieval, launch an LDAP query
  • ie: for openOSI LDAP directory use the following URI
    

    ldap://directory.openosi,org/ou=VirtualPeople,dc=openosi,dc=org?userCertificate?one?cn=FirstnameLastname1234

---

Return to top of page topJXPLORER

Verify your certificate purpose

You may use several tools to edit your certificate, including Windows, providing the file have an appropriate file extension corresponding to its format(.crt for DER format which is different from PEM). Conversion tools are out of the scope of this document.

When editing the certificate details under "Enhanced key usage" it should show
Client Authentication(1.3.6.1.5.5.7.3.2)
E-mail protection (1.3.6.1.5.5.7.3.4), optional for JXPLORER

When editing the certificate details under "key usage" it should show at least
Digital Signature, Key Encipherment

There is an openssl command to verify the purpose
In the example the certificate file name is: ldap.example.com.pem using PEM format

Or with Certification authority certificate file name: openosiCA1-DC.crt
Should answer as shown :
if you have a pem version of your certificate

Be Careful A certificate with no purpose (or Any Purpose : Yes) is a security risk. It could be misused if it is silently stolen from your host with its private key. It could allow anybody to impersonate you or any of your daemons over the Internet. This risk is greater when you have not appropriate Public Key Infrastructure managing revocation lists of certificates. It's a good practice to limit the certificate to its main purpose. Be aware that silent defaults of most HOW TO over Internet build any purpose certificates

---

Return to top of page topJXPLORER

check the content of your signed certificate for a correct cn

This cn should contain your user name fillingDN
The subject (DN) could be slightly different of the request because the Certification authority has removed the attributes it can't verify under its current policy (namely a level of assurance of class 1, 2 ...). This policy is indicated as a certificate practice statement or CPS

You may use several tools to edit your certificate, including your browser tools, providing the file have an appropriate file extension corresponding to its format(.crt for DER format which is different from PEM). Conversion tools are out of the scope of this document. For Internet Explorer check the Internet options/ content/ menu, for Firefox check tools/ options/ advanced/ menu.

When editing the certificate details under "Subject", it shows i.e
The order is not important (display order doesn't necessarily reveal coding order)
DC = com
DC = example
OU = People
CN = FirstnameLastname

When editing the certificate details with openssl command line, it should show:
In the example the certificate file name is: MyName.pem using PEM format

Note that DC and OU components MAY be empty. CN component MUST be present and reflect your user name, user id (or nick name)

---

Return to top of page topJXPLORER

Get your associated certificate private key

Either locally or from the online enrollment

If it is from an on line certification authority, you probably retrieve a bundle of

• Your private key
• You signed certificate
• The Certification Authority certificate(s)

It comes inside a keyset in PKCS12 format (with .p12 extension for MS Windows)
or in a keyset in JKS format (Java Key Store)

Be Careful With a JKS format the encryption password of your private key MUST be the same as the password of the Java Key store itself.

---

Return to top of page topJXPLORER

Retrieve the Certification Authority certificate(s)

If you used the openOSI Certification authority you will get the certificates there.

• Intermediate CA certificate of class 1: openosiCA1-DC
• Root CA certificate of class 3: openosiCA3-FR

You can also check our LDAP directory

If you have received a PKCS12 bundle of name MyName.p12 extract the CA certificate
Where MyNAmeCA.crt is the CA certificate

Example with Linux openssl

On client workstations you can use your favorite browser. Each one has a dedicated set of tools to import and export certificates in common formats. Do as follows:

1. Import your PKCS12 keyset
2. Check the CA certificates (issuer) of your certificate
3. Export the CA certificates in files (Microsoft .crt .der .cer format)

---

Return to top of page topJXPLORER

Check it is in JKS or PKCS12 format and convert it if necessary

JXPLORER uses 2 key stores:

1. a trusted CA / server key store (preferably in JKS format)
2. Client's private keystore (preferably in PKCS12 format)

We are interested by the later to store your private key and the associated certificate. Most of the available tools keyman or online CA will provide you with a PKCS12 file (Microsoft .p12 or .pfx extensions)

If you got your keyset in "pem" format mostly used in Linux environment, you need to use Linux openssl to convert them to a PKCS12 store.

Example
Where MyName.pem is your user certificate file
Where MyName.key is your private key file
Where MyNameCA.pem is your Certification authority certificates file

Create a bundle with MyNameCA.pem and MyName.pem
Where MyName.bundle.pem is the bundle file name

Create a PKCS12 key set with MyName.bundle.pem and MyName.key
Where MyName.p12 is the keyset file name
Where My_short_Name is an arbitrary display name in your keyset

Warning In case of chained CA certificates (Root CA and Sub CA), in regular pem format, the SubCA is first and the RootCA second. PKCS12 needs them in the reverse order before the client certificate. Therefore the bundle file must be constructed manually with individual certificates. Then edit the bundle and check for correct new line / line break between certificates blocks.

---

Return to top of page topJXPLORER

Update your JXPLORER certificates repositories

I recommend to keep JKS format for Trusted Servers and CAs
I recommend to set PKCS12 format for client certificates

To set you repositories go to the JXPLORER security tab:

---

Return to top of page topJXPLORER

Set the Java KeyStore of trusted Certification authorities

With the JAVA environment, comes a default JAVA system wide bundle file of common certification authorities named cacerts. For JAVA 6.0_01 it is located there:

C:\Program Files\Java\jre1.6.0_01\lib\security\cacerts

Set this path in the "advanced keystore options"

You MAY need to update this default JKS with your own CA certificate (the one that signed your certificate). You could do this later.

Be Carful When you set the default cacerts any operations (add, remove ....) from JXPLORER will modify this cacerts. This is OK, unless you use this cacerts for others applications that need different settings.

---

Return to top of page topJXPLORER

Set your personal keyset

You MUST set a personal key store. It is recommended to use PKCS12 format, because it's less common to get your certificates and key in a JKS format. i.e using keyman you cannot save the generated JKS with only the private key. You need to keep keyman running, waiting to retreive your signed certificate. To get a PKCS12 format also check certFormat

This is the default JXPLORER location for your keyset. Be careful, when upgrading to keep your keystore unchanged.

C:\Program Files\JXplorer\security\MyName.p12

Set this path in the "advanced keystore options"

---

Return to top of page topJXPLORER

Check your certificates configuration

Go to JXPLORER security/ client certificates/ menu
You should see an icon with "has private key" on your user certificate
In the example the user display name is manager (set in the keyset of PKCS12 or JKS format)

Go to JXPLORER security/ trusted servers and CAs/ menu
You should see:

• the CAs default list
• Your own CA (the issuer of your user certificate)
• The name of CA of the LDAP directory you wan to connect (if it is different than your issuer CA)

Note that your own CA and the LDAP's CA MAY be in CAs default list.

---

Return to top of page topJXPLORER

Set JXPLORER connection properties to your LDAPS server

Finaly clic the JXPLORER connection button to get the connection settings

And save it as a template with a meaningful name.

OSI stands for "Open Standards for Interconnection" from ISO / ITU
an OSI name is called a "Distinguished name" which is used in all OSI related technologies such as

• Certificates (X509)
• LDAP directories including Microsoft Active directory (X500)
• Military and aeronautical messaging systems (X400)

A "Distinguished name" (DN) is a collection of one or more of the following components

• CN Common name
• OU Organisation Unit
• O Organization
• C Country
• and many others like "givenname","sn surname","l location" ......

Example DN
DN: cn=My_full_name,ou=Related_Organisation_Unit,ou=other_related_unit,o=Company_name,c=country

or with the alternate DC scheme mostly used in directories.

DN:cn=My_full_name,ou=Related_Organisation_Unit,ou=other_related_unit,dc=example,c=com

Useful Information If you want to participate in the openLDAP referral service (ldap://root.openldap.org) you MUST use the DC scheme and set appropriate SRV records in your DNS.

Common meanings of OU are as follows:

• OU=Hosts
• OU=People # users
• OU=Services # Daemons

openOSI also uses in its naming scheme:

• OU=VirtualHosts
• OU=VirtualPeople # nicknames
• OU=PKI # Certification authorities

In principle you are free to use what you want as DN components value, unless you request a certification authority to certify these values. That is unless you intend a public use of these names to participate in an Internet of trust (similarly to the dns - Domain name system).

You MUST use a "Distinguished name" to generate a certificate request, see fillingDN

For additional information check the various OSI X500 and RFC

Useful Information There could be links between DNS and OSI naming scheme, especially when domain components are used for distinguished names. Some people stores DNS DB in an LDAP directory (like Microsoft optionally). Most people don't in order to keep loosely coupling between DNS and Directories. There is an interesting use of LDAP directories for certificates when storing these certificates and their revocation list (CRL) in the directories. Therefore you MAY imagine a scheme that facilitate directory searching for your certificate retrieval. That is unless you use a third part directory like openOSI (directory.opensosi.org). openOSI practice is to store your certificate in virtual OU unit according the openOSI naming scheme without relying on the distinguished name of the certificate. See certCheck, and CAcertsRetrieve

Filling your certificate subject

Warning You should be careful when choosing your certificate subject (DN). When authenticating with your certificate you will no more be asked for username and password. Very often you will be uniquely identified by your embedded e-mail address, but you also may be identified by your certificate subject. You cannot change your certificate's subject once it's signed by a CA.

The certificate subject is bind to the cryptographic material of your certificate (the private key). Here is the real nature of a certificate. Therefore a certificate for a user should be bind to some acceptable user ID. Check "Understanding OSI names" tab in topJXPLORER

Assign a user name to common name component. ie: cn=FirstnameLastname
The others, optional, parts of the subject are

1. Either a set of Organisation name and Country code_ ie: o=My_Organisation, c=US
2. Either a set of many Domain Components ie: "dc=example,dc=com" standing for example.com
3. Optionally you may have organisation units ie: ou=Finance or ou=people or ou=services
4. Optionally you may have additional cn as used by Microsoft naming scheme (cn=MyName,cn=Users,..)

Finally you obtain your subject value called a Distinguished Name abreviated as DN

1. example 1: cn=FirstnameLastname
2. example 2: cn=FirstnameLastname,o=My_Organisation,c=US
3. example 3: cn=FirstnameLastname,dc=example,dc=com
4. example 4: cn=FirstnameLastname,ou=people,dc=example,dc=com

This is the OSI naming scheme, also used in LDAP directories (like Microsoft AD) and X400 mail systems. If your certificate is stored in an LDAP directory, it could be stored in the same DIT (Directory Information Tree) as the one of it's Distinguished name, or it could be stored under another DIT.
openOSI stores the public signed certificates this way for class 1

• DIT is "ou=VirtualPeople,dc=openosi,dc=org"
• ObjectClass=top, ObjectClass=Person, ObjectClass=organizationalPerson, ObjectClass=InetOrgPerson
• cn=FirstnameLastname - The cn value of certificate subject
• sn=Lastname (default to cn value)
• mail=My.Name@example.com (default to verified e-mail address of the request)
• userCertificate="Binary form of your public certificate"
• OTIONS
  • givenName=Firstname

That is, if requesting an openOSI signed certificate, there is no need to fill something else than the common name as your user name, because openOSI will not certify additional information for its class 1 certification. Others parts like "o=My_Organisation, c=US" will be removed from the certificate unless you require a class 2 certificate (not available for now and subject to peer agreement).

Uniqueness of cn component in DN

Most of the time it is useful to have a unique value in that field, although, unique is always in a "local" context. The certificate subject alternative name refine (or replace) the subject (i.e: with e-mail address), but some authentication mechanisms like SASL EXTERNAL only uses the subject DN.

It is possible to put an e-mail address in the cn value, but many applications will fail (i.e: Liferay portal). Therefore, avoid this solution because you may have unpredictable situations with a given application.

Finaly, I recommend, when possible, to insert an "uid" component in the DN, which may look like this;
SASL_User_Name="dn:uid=My_name1234,cn=My_name,o=My_company,c=us"
Where "uid" in example, MAY be build like follows:
FirstName: John
LastName: SMITH
Last 4 digit of social security number: 1234 (or whatever algorytm)
uid=JohnSmith1234
cn="John SMITH"

This uid is supposed to be unique in the scope of a given directory (MUST be unique if you enforce controlled uid delivery). The email address remains the only worldwide unique id, if present in the subject alternative name. Note that a person MAY have multiple virtual identities, one for each of its email addresses. This is defaults for openosi.org online certification authority. The pre-registration for the certificate retrieval enforces uniqueness of the UID in the openosi directory

You may also put this UID value in the CN.

Handy Hint If you choose to generate yourself a certificate request (CSR) using keyman or any other tools including Linux based tools like openssl, it could be mandatory to fill all attributes like country, organisation, organisation unit, location .... We recommend you enter as few information as possible, entering blanks where appropriate, because a certification authority is supposed to verify all the requested attributes. This is not necessary for most authentications and is costly (however the CA could silently drop some of your unverified attributes).