Valid XHTML 1.0!

Valid CSS!

Powered by PHP

Get FireFox

1&1 Internet

Current News

Content-Security-Policy and Visual Studio Browser LinkFriday 14th July 2017
Visual Studio contains an excellent feature called Browser Link. It keeps things like style-sheets linked from your browser to your development studio. When you make a change to your CSS file, your browser immediately reflects the changes without having to refresh the page.

I thought it was a little bit of a gimmick to start off with, but to my horror, it stopped working on a web-site I've been working on recently just as I was about to add some features. The thought of having to go back to writing a load of CSS, alt-tabbing and then hoping it was largely doing the expected thing filled me with a mild panic.

I noticed that the "Refresh Linked Browsers" command was greyed out, and no browsers were being listed in the Browser Link Dashboard.

After much turning things off and on, hunting through menus and restarting programs I resorted to frantic Googling of the subject, to not much avail.

The Browser Link feature works through some javascript that is injected into your development code and uses a web-socket to keep the data flowing. And this is the where the problem was, my browser was blocking the javascript as I had recently introduced a Content-Security-Policy, which naturally didn't cover this injected code.

The fix is to allow the code in your CSP. It seems allowing default-src unsafe-inline http://localhost:* ws://localhost:*; script-src unsafe-inline http://localhost:* covers it off. But it's important that you remove these before publishing your site to a production environment.

Visual Studio has a handy feature for replacing Web.Config entries at publishing time, but the CSP header is a single line of text, so it's a bit fiddly to do and you have to replace the whole string with a live one. Not very good for testing out what you're pushing.

Java InstallCert.javaThursday 6th July 2017
A commonly accepted solution to the Java error "unable to find valid certification path to requested target" is to run the InstallCert code, a short program written by Sun which "fixes" the above problem.

Sun obviously is now defunct, but various copies of the code are kicking about the place.

The problem is - it doesn't work. And it seems to stem from a common misunderstanding of how SSL/TLS works and it is rife within the Java development community.

A server secured with SSL will present a certificate chain to the client with relevant certificates. The first certificate is the certificate proper. For example, if my website presents a chain, the first certificate in that chain is the one with the name that matches my website. All fine and good. It is this proper certificate that is the public part of the public/private asymmetric encryption. If you have this X509 public part you can decrypt.

But, with Public Key Infrastructure things go further to verify the integrity, as encryption without integrity is completely pointless (and potentially more dangerous due to false-sense-of-security). In PKI we use a Certificate Authority to sign certificates. This Certificate Authority is considered trusted to verify the identify of the web-site owner and guarantee that through a signed certificate. Whether you agree with operating system, Oracle and browser manufacturers deciding who should be trusted or not is a whole other debate.

The bundled trusted certificate authorities have their public certificate already installed on your system as such, there is no reason for a server to provide yet another copy of it. Generally it is considered best practice not to include the root CA in your certificate chain, just any intermediate authorities. If the client doesn't already have the certificate then it's not going to validate anyway.

What this means is, when running the InstallCert program, you will most likely be presented with the server certificate proper, but not the root certificate and it is most likely that the reason for the error is due to a missing root CA certificate in the Java trust store. Thus, you get nowhere fast.

The correct way to fix it is to manually import the relevant certificate authority certificate into the Java store. If the root CA isn't in the chain, you'll have to ask the server administrator for a copy.

Find your JRE directory and run:
bin/keytool -keystore lib/security/cacerts -import -trustcacerts -alias [shortname] -file /my/ca.crt

You'll be prompted for a password, as obviously your store needs to be kept secure (you did change it didn't you?). The default password being "changeit". Finally by typing "yes" when asked to confirm.

And that's it. No compiling programs. Simply add the certificate to the store.