Overview
We have configured our environment so that we can declare our own information outside the "
Project POM File" (
pom.xml) such as the "
Subversion" user id and password, the "
Issue Tracker" user id and password. But it is only the “
Maven” universe. We live in the bigger one, the integration universe. That means we need to know the other integrated system universe. Even we configure our credential / personal information with purpose to let “
Maven” to use them when it connect to each sever. It is just our credential / personal information. Since “
Maven” acts as a client, it should provide credential / personal information itself, too. Normally these communication is done via the “
SSL”, especially via the “
HTTPS”. There are some good practice to which I would like share.
The HTTPS Good Practice For The Client
Most of integration universe has been configured and deployed under the “
Apache HTTP” umbrella. As I've mentioned before, the “
HTTPS” is preferred. This means the “
Maven” will connect to them via the “
HTTPS”, too. The “
Maven” acts as a client, they act as a server for sure. What is the issues? Well, It is a very well known issue.
The Certificate Management For The Client
Normally the server provides its “
certificate” to the client for initiating the “
SSL” connection. The client will determine if this “
certificate” can be trusted. If yes, the conversation will be initiated.
If not the connection will be dropped. We may face a trouble like we cannot connect to server system shows me something about “
no trusted certificate found” or other close to this.
The HTTPS Client Configuration Good Practice
I am informing you about the good practice for the client side who would like to connect to the server via “
HTTPS”. If the client is a “
Java” environment, the “
Server Certificate” should be injected to the “
truststore”.
The “
Server Certificate” is not only limited to the server certificate itself, but also the “
Signer Certificate”, too. Please note the “
Signer Certificate” is a certificate of the trusted authority who sign the “
Server Certificate”. The signer also not be limited at one level, it can be more. It is called “
Certificate Chain”. During the checking & verifying If any of “
Certificate” inside this “
Certificate Chain” is trusted, It will be determined as trusted. This means if we have 3 levels “
Certificate Chain”.
The checking step is as following: -
- If the level 3rd is trusted, it is determined as trusted. The checking stop here.
- If the level 2nd is trusted, it is determined as trusted. The checking stop here.
- If the level 1st is trusted, it is determined as trusted. If not the system may show us as “no trusted certificate found”.
For me, I have 2 levels which are created by the “
openssl”. Anyhow it can be a 1 level as a self-signed as well.
By default the “truststore” is as following:-
Table 1: The default truststore for JRE
Default Trustsore for JRE |
<JRE_HOME>/lib/security/cacerts |
Example: C:/Java.Application/Sun/Java/jre1.6.0_21/lib/security/cacerts |
Table 2: The default truststore for JDK
Default Trustsore for JDK |
<JDK_HOME>/jre/lib/security/cacerts |
Example: C:/Java.Application/Sun/Java/jdk1.6.0_21/jre/lib/security/cacerts |
The injecting certificate command is as following: -
Table 3: The injecting certificate command
The injecting certificate command |
keytool -importcert -trustcacerts -alias <MY_ALIAS> -file <Certificate> -keystore <Truststore> |
Example: keytool -importcert -trustcacerts -alias myserver -file server.cer -keystore cacerts Please note: you may be prompted to enter the password, the default password is “changeit”. |
Some of them are not default.
Some of them may have their own configuration environment instead, especially the “
Subversion Client”. There are 2 types as global for whole client and per-user.
The server-wide
Unix:
/etc/subversion/servers
/etc/subversion/config
/etc/subversion/hairstyles
Windows:
%ALLUSERSPROFILE%\Application Data\Subversion\servers
%ALLUSERSPROFILE%\Application Data\Subversion\config
%ALLUSERSPROFILE%\Application Data\Subversion\hairstyles
REGISTRY:HKLM\Software\Tigris.org\Subversion\Servers
REGISTRY:HKLM\Software\Tigris.org\Subversion\Config
REGISTRY:HKLM\Software\Tigris.org\Subversion\Hairstyles
The per-user
Unix:
~/.subversion/servers
~/.subversion/config
~/.subversion/hairstyles
Windows:
%APPDATA%\Subversion\servers
%APPDATA%\Subversion\config
%APPDATA%\Subversion\hairstyles
REGISTRY:HKCU\Software\Tigris.org\Subversion\Servers
REGISTRY:HKCU\Software\Tigris.org\Subversion\Config
REGISTRY:HKCU\Software\Tigris.org\Subversion\Hairstyles
I prefer to use the per-user instead. Please note, I'm a “Windows Vista”, my configuration home for “
Subversion Client” is “
C:\Users\Charlee.Ch\AppData\Roaming\Subversion”. Normally the per-user configuration is created automatically by the “
Subversion Client”. If the “
Subversion Client” does not trust the “
Server Certificate”, you may face the message like this, “
Server certificate verification failed: issuer is not trusted”. It can be configured easily by using the “
Subversion Client” command via a command line, for me it is a dos prompt, as the following:
Table 4: Configure subversion client to trust the server certificate
Configure subversion client to trust the server certificate |
svn list https://<YOUR_DOMAIN/svn/path/to/repository |
|
During executing this command, you will be prompted about the “
Server Certificate”. Please press “
p”, for accepting this certificate permanently. Anyhow the system may prompt you to provide the credential, please enter it properly. The top most certificate for the “Server Certificate Chain” will be stored at your local as the following: -
Table 5: The stored server certificate folder
The stored server certificate folder |
<SVN_CLIENT_HOME>/auth/svn.ssl.server |
Example: C:\Users\Charlee.Ch\AppData\Roaming\Subversion\auth\svn.ssl.server |
Summary
At the moment, we understand that not only our credential / personal information should be configured, but also the “Maven” credential / personal information for itself should be configured, too. This will help us to achieve further integrating more simple and avoid the well know issues, such as the “
HTTPS Client Configuration”. We are well prepared and ready for the next step, “
Maven” integration with “
Subversion” and “
Issue Tracker”. I will post it soon, please stay tuned as always.