ServiceInsight has no option to allow self signed certificates

[gbiellem]

ServiceControl and ServicePulse can be reverse proxied through IIS. As part of that configuration SSL can be turned on. This works fine with a "real" certificate how ever If a self signing certificate is used ServiceInsight can not connect to the instance of ServiceControl as there is no mechanism to trust the certificate.

To test that this was the only issue I turned off the certificate check by adding the following to the app bootstrapper.cs and ServiceInsight worked fine.

## Not recommending this hack as the fix as it globally disables the cert check.
ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, sslPolicyErrors) => true;

Should we support self signing certs in ServiceInsight or not?

[HEskandari]

Do we know how common people run SC / SP through SSL?

Given it is needed, I'd say we can have a setting (controlled via Options and command args) to enable it. Would that work?

[gbiellem]

Do we know how common people run SC / SP through SSL?

I know I've helped a couple of clients with the setup but hard to know how wide spread the usage is.

Given it is needed

@HEskandari I was in two minds whether we need to support it which is why I didn't label it a bug, Perhaps we could just document that it is unsupported. That said the feedback to the user in this situation is not great.

I'd say we can have a setting (controlled via Options and command args) to enable it. Would that work?

Yeah that's one possibility or you could add a checkbox on the connect dialog and do it per connection,

[HEskandari]

There is also connection via command args that would fail if we go with connection dialog and checkbox.

Furthermore I had a look at Application Invocation and since at its current state it does not have the protocol included in the link, it will not support HTTPS (or anything other than HTTP).

I'm all for supporting it fully, including application invocation and other possible scenarios.

[adamralph]

@HEskandari and I discussed this today and we're leaning towards a solution of this shape:

• a change to the connect dialog (and the persistence data which backs it) to support a flag to skip the certificate check (as suggested by @gbiellem)
• a change to the command line parsing of the query string passed during application invocation to specify the protocol (HTTPS/HTTP) and a flag to skip the certificate check. This would be done in a backwards compatible way, and ServicePulse would have to be changed subsequently to pass the new query string params.

With this in place, we couldn't identify a need to have an application-wide option.

[HEskandari]

I think one more thing is missing - which we didn't discuss @adamralph.

If ServicePulse is being hosted in a secure environment (HTTPS), it needs to generate the ServiceInsight links (si:// links) passing that extra flag.

That, of course, would be out of scope for this issue, but needs to be tracked and there should be a coordinated release.

[adamralph]

@HEskandari in my comment I said

This would be done in a backwards compatible way, and ServicePulse would have to be changed subsequently to pass the new query string params.

Are you referring to the same thing?

Regarding coordinated release, I think we should be able to do this in a backwards compatible way in ServiceInsight, so the only hard constraint is that ServiceInsight change will need to be released first. The ServicePulse change can be released later. However, it may be surprising to a user that they can connect SI to an HTTPS SC when they launch the app themselves, but when they launch it from ServicePulse, it blows up, so from a UX experience it may indeed be better to release in lockstep.

[HEskandari]

@adamralph sorry, I initially missed the backwards compat part. That was what I was referring to. With that seems we've got everything covered.

[HEskandari]

@Particular/serviceinsight-maintainers Since we came to a conclusion, should this be closed and an improvement be opened based on the agreement?

[adamralph]

@HEskandari I agree.

[HEskandari]

This can be closed as I have opened relevant implementation issues.