Renew an Expired CA Signed Certificate

All digital certificates have a validity period and most clients and servers check the certificate expiry. If the certificate is expired it will no longer be considered as a valid certificate. The client-server communication will fail at the SSL handshake level. It is important to plan certificate renewal ahead of time. Neglecting this can eventually lead to a catastrophic situation such as major service outage.

Checking the validity period of the certificate.

This can be done in a couple of ways.

  1. If you have a public facing hostname. Use https://www.sslshopper.com/ssl-checker.html and provide the hostname of your server. SSL Hopper will list down all the information about the server certificate.
  2. If you are using a java keystore. View the certificate information with the following keytool command. The command will prompt for the keystore password.
    keytool -list -keystore <keystore_name.jks> -alias <cert_alias> -v

    This will display the certificate information in a human readable text. The validity period will be displayed as follows.

    Valid from: Sun Jun 18 19:26:25 IST 2017 until: Sat Jun 19 19:26:25 IST 2027
  3. If you have the cert file, you can use the below openssl command.
    x509 -in <certname.cer> -text -noout

    The validity period will be displayed as follows.

    Validity
                Not Before: Jun 18 13:56:25 2017 GMT
                Not After : Jun 19 13:56:25 2027 GMT
  4. If it is a website, you can even view the certificate information from the browser itself. All major browser provides this capability.

If the certificate is already expired or about to expire, the next step should be to generate a Certificate Signing Request (CSR) and get a new certificate generated from the CA.

Generating a certificate signing request.

To generate a CSR, you can use on of the following.

  1. If you have a java keystore, use the following command.
     keytool -certreq -alias <cert_alias> -file <CSR.csr> -keystore <keystore_name.jks>
  2. If you have the private key and the public key, use the following.
    openssl x509 -x509toreq -in <cert_name.crt> -out <CSR.csr> -signkey <private_key.key>

The generated CSR should be submitted to your certificate authority and get a new CA signed certificate. You can try this out this for free with http://www.getacert.com/signacert.html.

Importing the new certificate to a keystore.

Once you receive the CA signed certificate and if you are using a jks, import the new certificate to the keystore. When importing the certificate, make sure to import it with the alias you already have as the public certificate. The command is as follows.

keytool -import -v -trustcacerts -alias <current_alias> -file <ca_signed_cert.cer> -keystore <keystore_name.jks>

If you view the certificate using the keytool command, it should display the renewed certificate.

A few points to keep in mind is that. When renewing the certificate, use the same CA as you used when you first got the public certificate. If you use a different CA for certificate renewal, you will have to import the new CA certificate and the intermediate certificates to the keystore and the client’s trust store.

If the CA’s cert is not in the keystore, you will get the following error when trying to import the CA signed cert to the keystore. Therefore make sure to import the CA certificate and the intermediate certificates to the keystore in the correct order first.

keytool error: java.lang.Exception: Failed to establish chain from reply

Hope this helps 🙂

Adding Multiple Application Callback URLs in WSO2 API Manager 2.0

With WSO2 API Manager 2.0 it is possible to configure multiple application callback URLs or better yet, a regex pattern for the callback URL. In earlier versions, if the you wanted to use the same application for different service providers, you needed to configure an application for each service provider. Even if you send a different callback URL with the authorization/token request, from the serverside, the callback URL validation fails. Now, since we can configure a regex pattern for the callback URL, you will be able to configure multiple callback URLs. Here’s how you can achieve this.

Assume you have 2 service providers which needs to use the same application which has the callback URLs as

First login to the API store and create an application.

12

Click on Production Keys tab and set the callback URL as below. Then click on Generate Keys.

regexp=(https://myapp.com/callback|https://testapp:8000/callback)

4

An application will be created with the provided configurations in the server.

3

You can configure any regex pattern to match the callback URLs you want to register with the application. The only requirment is that the pattern should be followd by the string regexp= as shown above.

 

SAML SSO Error Handling in WSO2 Identity Server

This post explains on how to handle SAML SSO related errors in WSO2 Identity Server 5.2.0. In the SAML SSO flow, errors can be occurred due to several reasons. Some of them can be;

  • Signature verification failure of the SAML request or Response.
  • Mismatching ACS URLs in the request and the configuration.
  • Authentication failure in request path authentication.

The default behavior of the Identity Server is to redirect to the samlsso_notification.do page with the error information. And the page will display the error content on the page.

Screen Shot 2016-07-13 at 3.10.07 AM

Note that the error information will be sent to the page as URL params. A typical response URL will look like the following;

https://localhost:9443/authenticationendpoint/samlsso_notification.do?status=Error+when+processing+the+authentication+request%21&statusMsg=Please+try+login+again.&SAMLResponse=xxxxx&ACSUrl=http%3A%2F%2Fsamplesp%2F

Ideally, this error should be conveyed to the samlsso_notification.jsp. in the authentication endpoint. The following gist shows a modified samlsso_notification.jsp to POST the SAML response to ACS URL. However, this will only happen if the request URL consist with both SAML response and the ACS URL. Otherwise the page will display a generic error message. If needed, the page can be further modified to POST a static SAML response to a predefined ACS URL if those information cannot be extracted from the URL. But this will be not very straightforward when there are multiple ACS URLs since we won’t have enough information to determine from which service provider the login request initiated from.

In order to apply these changes to the product, either you can replace samlsso_notification.jsp in exploded authenticationendpoint.war directory located at [IS_HOME]/repository/deployment/server/webapps directory or you can checkout the source from [1], make the changes to samlsso_notification.jsp and build it. Once the source is built, you can drop the new authenticationendpoint.war file to the webapps directory. If there’s already a directory for authenticationendpoint, you’ll have to delete the directory as well.

Note: Even though this cannot be done to IS 5.1.0 out-of-the-box. By applying the fix mentioned in [2] you can achieve this in IS 5.1.0.


[1] – https://github.com/wso2/carbon-identity-framework/tree/release-5.2.0/components/authentication-framework/org.wso2.carbon.identity.application.authentication.endpoint
[2] – https://wso2.org/jira/browse/IDENTITY-4526

Configuring Intellij IDEA to overcome Checkstyle ‘Wrong order for import’ issues

If you have integrated the Maven Checkstyle Plugin [1], you are most likely to encounter build failures during checkstyle execution with the message:

'Wrong order for 'xxx.xxx.xxx' import'

If you are developing in IDEA, even if you optimize imports [2], you are most likely to get this error due to the ordering of java and javax imports. The problem is, by default IDEA order the javax imports after java imports (in version 13 and 14 at least). At first you try to fix this by manually arranging the imports, but it gets kinda annoying when this happens frequently. Luckily there is a way we can fix this by configuring IDEA to satisfy the checkstyle requirements.

Open the ‘Settings‘ (or ‘Preferences‘ in mac) window and goto Editor > Code Style > Java. Click on ‘Imports‘ tab. In ‘Import Layout‘ area, you can arrange the import order by selecting the import type and clicking on the arrow (see image below). Once the changes are done apply the new settings. Now IDEA will make the import optimization according to the new configurations.

Screen Shot 2016-04-26 at 5.29.16 PM

 

[1] – https://maven.apache.org/plugins/maven-checkstyle-plugin/
[2] – https://www.jetbrains.com/help/idea/2016.1/optimizing-imports.html?origin=old_help

Security Token Persistence in WSO2 Identity Server 5.1.0

When we apply a security policy to the Security Token Service, a token store will also be specified. If we navigate to the registry path /_system/config/repository/axis2/service-groups/org.wso2.carbon.sts-5.0.7/services/wso2carbon-sts/policies/ and view the content of the applied policy, the token store details are included as follows

<rampart:tokenStoreClass>org.wso2.carbon.identity.sts.store.DBTokenStore&</rampart:tokenStoreClass>

The token store class is picked from the following property in carbon.xml file.

<TokenStoreClassName>org.wso2.carbon.identity.sts.store.DBTokenStore</TokenStoreClassName>

However, the default DBTokenStore is an in-memory token store (regardless of what the name implies). Therefore, with time, the token store will retain a significant amount of JVM heap if a large number of users obtains security tokens. Also, the issued tokens will be invalid after a server restart.

If required, we can change the token store to a DB based one. For that change the TokenStoreClassName in carbon.xml as follows.

<TokenStoreClassName>org.wso2.carbon.identity.sts.store.JDBCTokenStore</TokenStoreClassName>

After changes, restart the server and re-apply the security policy to the Security Token Service. The tokens will be persisted in IDN_STS_STORE table.

Remote Profiling WSO2 Products with JProfiler

This post contains the steps to remote profile a WSO2 server using JProfiler

Setup Details:

  • WSO2 Identity Server 5.1.0 – Beta
  • JProfiler 9

You can download JProfiler from here.

Once JProfiler is downloaded and extracted, navigate to JProfiler, bin folder and run jpenable command.

Select the GUI Profiling mode and the program will request the profiling port. The default port will be 31757. If you don’t have a requirement to change the port, just press enter  so the profiling port will be the default port.

jprofiler9/bin$ ./jpenable
Connecting to org.wso2.carbon.bootstrap.Bootstrap [30483] ...
Please select the profiling mode:
GUI mode (attach with JProfiler GUI) [1, Enter]
Offline mode (use config file to set profiling settings) [2]
1
Please enter a profiling port
[31757]

You can now use the JProfiler GUI to connect on port 31757

Then open JProfiler in your local machine, start a new session (Session > New Session or ⌘N in Mac) and attach the session to remove Identity Server instance using it’s IP and profiling port.

JProfiler-New-Session

Hope this helps… 🙂