Check SSL certificate of asset websites (a.k.a proof-of-authenticity)

[ghost]

Requested by several users, and generally a good idea.

http://blog.coinprism.com/2014/09/10/proof-of-authenticity-of-cryptoassets/

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/6598617-check-ssl-certificate-of-asset-websites-a-k-a-proof-of-authenticity?utm_campaign=plugin&utm_content=tracker%2F686853&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F686853&utm_medium=issues&utm_source=github).

[unsystemizer]

You could say we already do this: if you specify https://, then HTTPS will be used. The site that displays this output from Counterblock API can validate the certificate on its own. If the site refuses self-signed or "invalid" certificates, then it can not display the contents, or display asset details so that it's clear the certificate didn't validate.

We don't validate certificates, but we could.

• Change documentation to notify asset owners that https:// will be validated
• Change HTTPS verification to True in: https://github.com/CounterpartyXCP/counterblock/blob/master/counterblock/lib/util.py#L252
  But then any invalid certificates would cause an error and we'd have to not fetch that data. If we still accommodated invalid SSL certificates, then it'd be the same as it is now (we don't differentiate between valid and invalid, it's up to the user).

Maybe it'd be okay to enforce validation, but someone should take a look at the current situation and see how many certificates are invalid, just to estimate the impact.