SSL Certificate Not Working Localhost

This morning my machine updated and Chrome no longer saw my SSL certificate as valid. it was complaining about a SAN (Subject Alternative Name). Through the following links, it became apparent that Chrome had updated. Using the following links, I was able to come up with the step by step guide to resolving the issue.
Links:

  1. Delete the existing key with the following command:

keytool -delete -alias mysample.com -keyalg RSA -keystore “C:/Program Files/Java/jdk1.8.0_45/jre/lib/security/cacerts”

2. Generate a new key with a SAN (Subject Alternative Name) with the following command:

keytool -genkey -alias mysample.com -ext san=dns:mysample.com -keyalg RSA -keystore “C:/Program Files/Java/jdk1.8.0_45/jre/lib/security/cacerts”

3. Restart the machine

4. Open Chrome, Chrome Settings > Show advanced settings > HTTPS/SSL > Manage Certificates. Delete the existing certificate from the ‘Trusted Root Certification Authorities’ and ‘Trusted Publishers’ tabs respectively. If you are creating your first SSL certificate on your localhost, you can skip this step (step 4)

5. Restart Chrome

6. Navigate to the HTTPS page and press F12 to open dev settings, open the security tab and View Certificate

7. Export the certificate and name it mysample.com (or whatever your alias is)

8. Open Chrome, Chrome Settings > Show advanced settings > HTTPS/SSL > Manage Certificates. Import the new certificate to the ‘Trusted Root Certification Authorities’ and ‘Trusted Publishers’ tabs respectively.

9. Restart machine

Advertisements

Updating Your Local SSL Certificate

Previously: Create SSL Certificate for HTTPS localhost on Tomcat 7 Chrome and Internet Explorer

The local certificate will expire after 3 months. here is how to update it.

1.Inspect your tomcats’ server.xml file to see what java it is using. So lets say it is using:
C:\Program Files\Java\jdk1.XXX
2.Delete the expired certificate with the following command:
keytool -delete -alias gleniris.com -keyalg
RSA -keystore “C:\Program Files\Java\C:\Program Files\Java\jdk1.XXX\jre\lib\security\cacerts” – the password is by default changeit
3.restart the machine
4.generate a new cert with the following command:
keytool -genkey -alias gleniris.com -keyalg
RSA -keystore “C:\Program Files\Java\C:\Program Files\Java\jdk1.XXX\jre\lib\security\cacerts”

You are now asked to enter your name. enter your name as whatever value your alias is. In my case I entered the name as gleniris.com
5.Copy the certificate which you have generated:
Attempt to navigate to the secure section of your site. For me, it was (Note the HTTPS protocol):
https://my.gleniris.com:8443
Using the 3 dot menu, more tools, developer tools, security tab, and Click the Certificate Information > Details tab > Copy To file > Export. Save it as the defaut .cer file type. Save it with the same name as you alias. For me this file is named:
gleniris.com.cer
6.Create an entry in the trusted certificate publishers directory of your machine
Open a command window and type
certmgr.msc
Expand the ‘Trusted Publishers’ directory. Using the menu bar, select action >All Tasks >Import, and import the file you created in step 4. Repeat this process in the ‘Trusted Root Certification Authorities’ directory.
7.Restart your machine.

Stop seeing the ‘Form Submission’ when you click back

You need to familiarise yourself with the PRG ‘design pattern’

 

Post-Redirect-Get Pattern in Spring MVC

Cloudinary, jQuery and HTML to upload image

I have found the Cloudinary documentation poor. Here I have listed the code and steps to upload images to your cloudinary account using jQuery.

COPYING AND PASTING THIS WONT WORK, YOU MUST READ TEXT INSTRUCTIONS UNDERNEATH!

 

 

HTML and jQuery

<!DOCTYPE html>
<html>
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″>
<title>JSP Page</title>

//PLACE OPENING SCRIPT TAG HERE

$(document).ready(function () {
// $(“#cloudinary-input”).attr(“data-form-data”, jsonData);
console.log(Math.floor(Date.now() / 1000));
});
function upload() {

var params = {
api_key: ‘1112222’,
public_id: ‘samplepublicid’,
timestamp: ‘1448741653’, //Math.floor(Date.now() / 1000);,
cloud_name: ‘mycloudname’,
signature: ‘9a19e11286b77e7e4f9ba2cb1f8dd4cb40cd67bc’

};

var input = $(“#cloudinary-input”);
input.attr(“data-form-data”, JSON.stringify(params));
input.bind(“fileuploaddone”, function (e, data) {
test(data);
});
input.cloudinary_fileupload();
input.fileupload(‘option’, ‘formData’).file;
input.fileupload(‘add’, {files: document.getElementById(“cloudinary-input”).files});
}

function test(data){
alert(‘success’);
}

//PLACE CLOSING SCRIPT TAG HERE

</head>
<body>
<h1>Hello World!</h1>
<form >
<input id=”cloudinary-input” name=”file” type=”file” class=”cloudinary-fileupload”
data-cloudinary-field=”image_upload”
data-form-data=”” />
<input id=”image_upload” type=”hidden” value=””/>
<input type=”button” value=”Upload” onclick=”upload()”/>
</form
<div class=”.cloudinary-fileupload” src=””/>
</body>
</html>

Ok, that is the base. Now read this:

You need to download the jquery files listed below and put them in the head of your HTML file. You can get them from Cloudinarys jQuery github js directory here. Make sure you have the src attribute pointing to where you’ve downloaded them.

Untitled

You need to customise the value of the ‘params’ object to match your own. A guide to where you can find the values is here:

  • api_key – You can see this in your cloudinary dashboard.
  • public_id – An optional attribute, make it up.
  • timestamp – This is a unix timestamp. you can generate it with the following javascript: Math.floor(Date.now() / 1000); YOUR TIMESTAMP CANNOT BE MORE THAN 1 HOUR OLD
  • cloud_name – This can be seen in your cloudinary dashboard too, at the time of writing, I saw it in the top right hand side of the screen.
  • signature  – THIS IS THE PART WHERE YOU NEED TO PAY ATTENTION. SEE BELOW

Generating a Signature for Cloudinary jQuery Call

  1. lay our the parameters you are using in a string as such: public_id=samplepublicid&timestamp=1448741653. The format is key=value&key=value. They must be in alphabetical order.
  2. In the cloudinary dashboard, find your ‘API Secret’. Assume my API secret is: ‘glenirissecret’.
  3. Tag your secret on to the end of your newly formed string, eg: public_id=samplepublicid&timestamp=1448741653glenirissecret
  4. Generate a SHA1 hash code. You can Google PHP or Java code to do this, however, you can also use this site to do so:     http://www.sha1-online.com/
  5. You should now have a hash value of 9a19e11286b77e7e4f9ba2cb1f8dd4cb40cd67bc
  6. The hash code you generate is now the value of your signature param.
  7. Substitute into your values to my code above and refresh the HTML. Upon uploading your image, you should see an alert box with ‘succcess’!

With inspiration and help from:

Cloudinary Support Form

Telerik Forum

Apache Tomcat fails to start from Netbeans

starting-of-tomcat-failed-netbeans

Log Message:

‘127.0.0.1’ is not recognized as an internal or external command,
operable program or batch file.

The solution is taken from Stack Overflow with thanks to Sudeepta

I have faced the exact problem in apache-tomcat-7.0.56 and apache-tomcat-8.0.14 with netbeans7.4 and netbeans8. I installed tomcat from zip file. I fixed it by changing catalina.bat file in tomcat bin directory.

Find the bellow configuration in your catalina.bat file.

:noJuliConfig
set "JAVA_OPTS=%JAVA_OPTS% %LOGGING_CONFIG%"

:noJuliManager
set "JAVA_OPTS=%JAVA_OPTS% %LOGGING_MANAGER%"

Just remove the double quotes

:noJuliConfig
set JAVA_OPTS=%JAVA_OPTS% %LOGGING_CONFIG%

:noJuliManager
set JAVA_OPTS=%JAVA_OPTS% %LOGGING_MANAGER%

Now save and start your tomcat from NetBeans. It works for me in apache-tomcat-7.0.56 and apache-tomcat-8.0.14.

Interface Segregation Principle

Below is taken directly from http://www.oodesign.com/interface-segregation-principle.html

Motivation

When we design an application we should take care how we are going to make abstract a module which contains several submodules. Considering the module implemented by a class, we can have an abstraction of the system done in an interface. But if we want to extend our application adding another module that contains only some of the submodules of the original system, we are forced to implement the full interface and to write some dummy methods. Such an interface is named fat interface or polluted interface. Having an interface pollution is not a good solution and might induce inappropriate behavior in the system.

The Interface Segregation Principle states that clients should not be forced to implement interfaces they don’t use. Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one submodule.

Intent

Clients should not be forced to depend upon interfaces that they don’t use.

Example

Below is an example which violates the Interface Segregation Principle. We have a Manager class which represent the person which manages the workers. And we have 2 types of workers some average and some very efficient workers. Both types of workers works and they need a daily launch break to eat. But now some robots came in the company they work as well , but they don’t eat so they don’t need a launch break. One on side the new Robot class need to implement the IWorker interface because robots works. On the other side, the don’t have to implement it because they don’t eat.

This is why in this case the IWorker is considered a polluted interface.

If we keep the present design, the new Robot class is forced to implement the eat method. We can write a dummy class which does nothing(let’s say a launch break of 1 second daily), and can have undesired effects in the application(For example the reports seen by managers will report more lunches taken than the number of people).

According to the Interface Segregation Principle, a flexible design will not have polluted interfaces. In our case the IWorker interface should be split in 2 different interfaces.

// interface segregation principle - bad example
interface IWorker {
	public void work();
	public void eat();
}

class Worker implements IWorker{
	public void work() {
		// ....working
	}
	public void eat() {
		// ...... eating in launch break
	}
}

class SuperWorker implements IWorker{
	public void work() {
		//.... working much more
	}

	public void eat() {
		//.... eating in launch break
	}
}

class Manager {
	IWorker worker;

	public void setWorker(IWorker w) {
		worker=w;
	}

	public void manage() {
		worker.work();
	}
}

Following it’s the code supporting the Interface Segregation Principle. By splitting the IWorker interface in 2 different interfaces the new Robot class is no longer forced to implement the eat method. Also if we need another functionality for the robot like recharging we create another interface IRechargeble with a method recharge.

// interface segregation principle - good example
interface IWorker extends Feedable, Workable {
}

interface IWorkable {
	public void work();
}

interface IFeedable{
	public void eat();
}

class Worker implements IWorkable, IFeedable{
	public void work() {
		// ....working
	}

	public void eat() {
		//.... eating in launch break
	}
}

class Robot implements IWorkable{
	public void work() {
		// ....working
	}
}

class SuperWorker implements IWorkable, IFeedable{
	public void work() {
		//.... working much more
	}

	public void eat() {
		//.... eating in launch break
	}
}

class Manager {
	Workable worker;

	public void setWorker(Workable w) {
		worker=w;
	}

	public void manage() {
		worker.work();
	}
}

Conclusion

If the design is already done fat interfaces can be segregated using the Adapter pattern.

Like every principle Interface Segregation Principle is one principle which require additional time and effort spent to apply it during the design time and increase the complexity of code. But it produce a flexible design. If we are going to apply it more than is necessary it will result a code containing a lot of interfaces with single methods, so applying should be done based on experience and common sense in identifying the areas where extension of code are more likely to happens in the future.

Apache Tomcat Severe Error

SEVERE: Error configuring application listener of class com.sun.faces.config.ConfigureListener
java.lang.ClassNotFoundException: com.sun.faces.config.ConfigureListener

 

Some things to note:

  1. Notice the time stamp beside the exception, this may not be an existing problem. If it happened today, it will always be shown on server startup as tomcat only creates a new log when the date changes (ie new log every day).
  2. Also, when running netbeans, although you may have cleared the logs directory in Apache Tomcat, you will also need to clean them in the catalina base directory. Right click on Tomcat in netbeans and you will see where the catalina base is located. This will then allow you to navigate to the logs to delete them.

For me, this problem was solved by adding

jsf-api.jar
jsf-impl.jar

 

to the lib directory under WEB-INF directory of my project.