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.

  1. Delete the existing key with the following command:

keytool -delete -alias -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 -ext -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 (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

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 -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 -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
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):
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:
6.Create an entry in the trusted certificate publishers directory of your machine
Open a command window and type
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.

Security Basic Best Practices

1. Always validate user input. The user could stick html or javascript into text box. Malicious users can embed links in your page and change href of your links. You can run regex against input to remove suspicious, non alpha numeric characters that may be part of a script.

2.When taking info from a request., eg request.getParameter, you must validate it. Similar to point 1 above.

3. Add a timeout to a users sessions using a MAC code.

4. HTTP ‘posts’ are for updating,  HTTP ‘gets’ are for reading.

5. Set the default char set at top of page to reduce the types of escapes and canonicalization tricks available to bowld pups. eg content type =text/html charset=iso-8859-1

6. The less information sent back to the client in a failed request/operation,  the better.just say operation failed, dont say why. If you give a clue as to why, a hacker might take advantage of this. A simple example is how web systems used to say ‘Invalid password’ or ‘no user with that username exists’. This lets a hacker know he has at least got an existing username and can then run password cracking software against that username.

7. A note on passwords:

  • Tunnel the request thru ssl/tls
  • Only give a simple failure message for failed login attempts . don’t specify the reason the login failed.
  • Log failed attempts but not the password which was attempted
  • Use a strong salt based cryptographic one way function based on hash for password storage.suggest PBKDF2
  • Provide secure mechanism to change password
  • Password reset should never send the old password out. Send a temporary password.
  • Passwords should be strong and clear instructions should be on screen to facilitate this

8. Session id should use a good random number generator. Use the system CRNG or
Byte test [20];

SecureRandom crng = new SecureRandom ();
crng.nextBytes (test)


George Graham, a master of security

SSL Certificates

Its recommended to use of a certificate from a public Certificate Authority (CA) included in the JDK/JRE list of recognized CAs. However, a self-signed certificate can also be used. Self-signed certificates require the signing CA’s key be installed on any machine that uses the application in question for certificate validation. If the CA key for the self-signed certificate is not installed on a machine where someone is attempting to use the application in question, communication will not be allowed.

What is SAML

SAML is a protocol that defines some standard entities whose names get tossed around (SP, IdP, etc).

Generally, a user is looking to use “something” (gmail) so they will type in the address of the service ‘provider’ (
Each service provider will have a security policy that they define/control,  in things like gmail it takes the form of “you must be identified to access this service”. If the SP receives a request that has not yet had identity confirmation provided, the SP has to involve other parties as it purely provides a service, not identification
In a SAML based authentication, the service provider does not do the authentication/identification themselves, but it must know ahead of time who they are willing to trust to perform that task.  Each service provider must have at least 1 identity provider (can theoretically have N if they configure it that way) that they trust to guarantee the identity of someone
IdP’s generally use usernames and passwords (or perhaps user/pass/2 factor code a la google accounts) to confirm who a user is and then create a time limited statement of identity confirmation (this is the SAML assertion) must be digitally signed to prevent tampering.
The Service provider receives the assertion and verifies that it came from a trusted IdP (this is why certificates have to be passed around and configured, which is a bit of a pain,  but without them, there is no way to validate who signed what).  Assuming all is good and the user came back from the IdP with a good assertion signed by the IdP’s known certificate,  the SP allows them access (this is the point at which html/js/image/etc resources typically start loading.
For the gmail example,  when you type in,  if you’re not logged in,  you get redirected to google accounts where you provide your username/password2 factor code,  and if you get it all right,  you get sent back to the gmail site, it’s at this point that you see the gmail ‘loading’ initial screen and then the full gmail app comes up.

Security Issue for Java and MySQL or SQL

The most basic vulnerability is to leave the database operating on the default port of 3306 with the default user name and password. Ensure that this port is not open to the web.

SQL Injection Vulnerability

To protect against SQL Injection, it is necessary to avoid methods which take an argumenrt which is directly used in an SQL query.

The solution is a two setp process.

  1. First, validate the input argument against a regex or caught parse exception. Therefore you will know, if the method is supposed to accept a String containing a int, or an entire set of digits, you can be sure that this is the case. This ensures you are not using user input to directly query the database without validating it first.
  2. The second prevention step is not to use a direct SQL query. Instead use a prepared statement. This means that you are not using string concatenation or string replacement to query the database. If this were the case, an attacker can pass your method an SQL statement which will then be run against your database.