I am trying to setup Grafana using the Azure AD configuration in its OAuth setting and the only way to get it working is by using a certificate. Which is fine except for the part where they will not accept privately signed certificates. Unsurprisingly, it throws the following exception:
Error getting user info: Get https://: x509: certificate signed by unknown authority
Do you know a work around? Or the right setting to make grafana use a privately signed cert?
You can add tls_skip_verify_insecure = true to the [auth.generic_oauth] block.
I try different solutions and only two works for me:
You can set tls_skip_verify_insecure = true in grafana.ini file, but is not a good solution because is not secure like is said in the documentation of Grafana (https://grafana.com/docs/grafana/latest/auth/generic-oauth/):
"tls_skip_verify_insecure controls whether a client verifies the server’s certificate chain and host name. If it is true, then SSL/TLS accepts any certificate presented by the server and any host name in that certificate. You should only use this for testing, because this mode leaves SSL/TLS susceptible to man-in-the-middle attacks."
The other solution, and the one that I´m currently using, is adding my CA (the one that I use to sign my certificates) to the trusted CA's of Grafana in the /etc/ssl/certs/ca-certificates.crt file (adding it at the end of this file).
I hope this helps you, it works for me, but I´m not sure if it's the best solution.
Related
I am trying to wrap my head around certificates and any help is appreciated. So far this is what I understand, please correct me if I am wrong.
When using the browser when I navigate to the https site the browser downloads the certificate(without the private key) and then continues to send the data over https?
I have come across some sites (especially when developing) that require you to install the certificate on the local machine before making a service call. What is the purpose here and how does it work?
I have also seen some scenarios where you need to install the certificate on the client machine for authentication purposes for example if you are using an email client, how does this work?
When using the browser when I navigate to the https site the browser downloads the certificate(without the private key) and then continues to send the data over https?
No, the browser and the server stablish a SSL/TLS secure channel with a symmetric encryption key. During the handshake process the server presents the https certificate and digitally signs some data with the private key as a proof of authenticity.
I have come across some sites (especially when developing) that require you to install the certificate on the local machine before making a service call. What is the purpose here and how does it work?
The client must trust the server certificate. Usually it has a list with the Certification Authorities for which certificates are accepted. For other certificates is needed to add them to the trust list. If not, the communication will be rejected
I have also seen some scenarios where you need to install the certificate on the client machine for authentication purposes for example if you are using an email client, how does this work?
Probably the same case as the previous one. Also the public part of the certificate of a user can be used to encrypt a message for him
We've an ASP.NET MVC4 app where there is a part which should be secured through client certificates.
When anyone wants to connect to this part of the app, browsers should ask them for a client certificate, once they select it, our server will get it, check it's validity and show the content.
Ok, I'm getting trouble with the select certificate part. Before setting it just to one folder on views content, I'm trying to configure this on the global app.
I've set SSL to be required, and also set require client certificates on SSL Configuration on apps configuration on IIS.
I've enabled the iisClientCertificateMappingAuthentication (although I've set no mapping yet)
When I try to access the app both, Firefox and Chrome, return a 403 forbidden error, stating that I have no access to the app with the credentials provided.
I've a client certificate installed on my local machine and the CA who created this certificate as a trusted root certificate on server local machine.
I'm not being prompted for certificate.
If I uncheck the "require" from client certificates on SSL Settings, I can access the app through https.
This is the first time I work with client certificates, so it's being a bit confusing and maybe I'm not giving enough info. Feel fre to ask for further info on the comments.
EDIT: I've exported the client certificate, copied it to the server and checked it there. The certificate shows as valid and every element in the certification chain seems to be recognized in the server.
I've checked IIS logs also, and the error I'm getting is 403.7, so the certificate is not being issued to the server or it's invalid.
Now... I've checked that the certificate is valid on the server, it's correctly installed on the client but it's not getting to the server or is not beign validated there... what am I missing here?
Ok, finally I've found the problem, it's related to the buffer size reserved for the list of trusted certification authorities.
Check this kb article:
https://support.microsoft.com/en-us/kb/933430
TL DR; To solve the problem just add a new entry in the registry at:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
named SendTrustedIssuerList as a DWORD value with value 0.
This way, the server won't send the trusted certification authorities list, so browsers will display the complete list of certificates to the user.
I can't find the answer to this question online:
I have set an apache server with mod_ssl, using the guide at the bottom here:
https://help.ubuntu.com/10.04/serverguide/httpd.html
I am only using this privately to login to PHPMyAdmin and other control panels.
Using only SSL, is my connection securely encrypted, so logins are not passed as plain text? Or do I need a self-signed certificate?
Google Chrome says there is a certificate, but that it does not match the URL and that it is not trusted.
That tutorial says:
The default HTTPS configuration will use a certificate and key generated by the ssl-cert package. They are good for testing, but the auto-generated certificate and key should be replaced by a certificate specific to the site or server.
This means, that's there's a default certificate involved. You should generate your own certificate for personal use and look for nasty things when it changes during your connections. You can do that with tools like OpenSSL. If you want to secure a public site, you would need to buy a certificate from a respected authority, so plain users wouldn't be bothered to add the certificate to their browsers and they would also not track if that thing changes.
I am working on a website that exposes an xml gateway that clients can submit an xml request to and get an xml response in return. The website/company has been purchased by a larger organization and has been migrated into their infrastructure. The existing production site is using an ssl certificate by a particular certificate authority but the larger organization uses certificates issued by a different certificate authority. We have tried run a test with one of their clients and they are getting an SSL handshake error. The original developer says that the only way to get it to work is to restore the original SSL certificate and not to use the new ones. I am looking for some guidance or direction to diagnose this issue, so any help would be appreciated.
What the developer says, from the description is sensible to me, but the problem is theirs.
To verify that this is exactly what is happening you can do a wireshark capture and then decode the flow as SSL. If the problem is that the client do not trust the certificate send by the server and reject the connection you will see it in the handshake in the wireshark.
If you use a java client you could run it with -Djavax.net.debug=ssl to see the ssl messages from within java.
If this is indeed the problem then you must configure the client's truststore to have the certificate send by the server (which is the original one).
If this configuration is possible of course... This depends on the application
UPDATE:
Well if you migrated to a new CA, i.e. you deploy a new certificate in your interface, then sorry to say, it is "your" -meaning the server side- error.
IMHO, if it is possible, you should redeploy the old certificate for a prespecified period, communicating to all the stakeholders that you plan to migrate to a new certificate signed by a new CA, so that the clients don't break
Then it is their responsibility, within that period, to "fix" their client apps to be able to accept the new certificate. This can be as simple as configuration i.e. importing the certificate to a truststore, to as "complicated" as to change code and rebuild the client app (e.g. if the new issued certificate does not have extensions that the code is verifying or the CN has changed etc).
If it is not possible to redeploy the old certificate then, you just have to communicate the change to all stakeholders and then, they should "fix" it accordingly (as mentioned above)
I need to implement a SSL certificate for a website, I've got three questions after some research.
1) I believe i need to buy a SSL certificate and ask my host to install it. My question is do you need to alter any code for the website for the certificate?
2) Before I buy the certificate, the website is going to be built for a couple of month at least. I'm just wondering is there a developing SSL certificate I can use for the developing environment?
3) Or do I have to use self assigned certificate? If so are there any good tutorials on how to create a SSL self assigned certificate on a local machine (wamp) and a developing url site?
Thank you very much.
Sam :)
1) No, you do not need to alter any code on your website at all in order to use an installed SSL certificate. It is as simple as prefixing your desired destination link with the HTTPS: protocol specification instead of the typical HTTP: protocol. However, if you want to determine if your site visitor is using an encrypted page before they do something, such as submit a web form with potentially sensitive data, then depending on what you are developing your site in, you will need to detect if the current page request has been sent over HTTP or HTTPS, then if it is an HTTP requested page, you probably want to redirect the page request to the HTTPS version before proceeding.
2) Other than creating your own "self signed" certificate (more on this in #3), no your only option for a publicly valid SSL certificate is to obtain one from a publicly recognized Certificate Authority (CA). Long story short, a certificate of the same key length using the same encryption standard supported by your server and visitor's web browser, is no stronger or weaker regardless of vendor for purposes of encryption. So you can simply shop by price for your SSL certs. I have no affiliation with GoDaddy, but have been using them for years for public SSL certificates.
3) You certainly can create your own self signed certificate. The methods for doing this vary based on your host server and version. The limitation to a self signed certificate, is that if you go to share this with anyone, you get that warning message from your browser that the certificate is not published from a verifiable source. In most current browsers, it looks like a big scary message that something is wrong and they attempt to warn your user away from doing this. However, of course, there is certainly nothing wrong with using a self signed certificate. This is obviously true for your own development uses. Even a self signed certificate of the same key length and encryption method is as cryptographically secure as a commercially provided certificate. If you want to use a self signed certificate, just search for instruction for doing that for your server OS and version for details. Once it is installed, you will get the warning from your browser when you try to browse to a page over HTTPS. Your browser should show you an option to permanently remember and accept your self signed certificate, after which you will no longer see that warning while that certificate remains installed and valid.