I have an API I control at my plant. I want to call this API from Epicor Public Cloud in a BPM.
My API has a self signed certificate. I know how to disable the checks, so I can get it working through
RestSharp without any issues. My concerns are with what are the risks here of disabling the checks,
and what checks can/should I do on my own to minimize the risks. The code included below has the area tagged with the comment “//What should I put here instead?”.
I really don’t want to deal with getting a certificate. The self signed should be fine I believe, but I know
I need to do some checking here to minimize risks, and I just don’t know what they are.
The data being sent is not sensitive, but you never know what I may do in the future.
What say you both types of experts, (security) and (programmers)??
//using RestSharp;
//using RestSharp.Authenticators;
string IP_Address = "123.123.123.123";
string IP_Port = "12345";
string Print_Function = "someUrlPart";
const string API_Key_Label = "API-Key";
const string API_Key = "blablahblablahblablahblablahblablahblablahblablahblablahblablahblablahblablahblablahblablahblablah";
string serverUrl = $"https://{IP_Address}:{IP_Port}/{Print_Function}";
string sampleContent = @"
{
""labelData"":
{
""burger"": ""time"",
""all"": ""thetime""
}
}
";
var client = new RestClient(serverUrl);
//Disables certificate verification
client.RemoteCertificateValidationCallback = (sender, certificate, chain, sslPolicyErrors) =>
{
//What should I put here instead?
return true;
};
var request = new RestRequest();
request.AddHeader("Accept", "*/*");
request.AddHeader(API_Key_Label, API_Key);
request.Method = Method.POST;
request.AddParameter("application/json", sampleContent, ParameterType.RequestBody);
var response = client.Execute(request);
You are calling an API you are hosting from the WAN over the public internet?
If that’s the case I would protect it from egress by doing things like IP Whitelisting for starters
Self-signed is a bad idea unless you are dealing in an internal network and is still not ideal. You want to have a certificate error if the certificate is not recognized. You are asking for risk assessment but not willing to fix a major security gap.
If you still don’t wish to fix this, you should not blindly whitelist every cert, and what you should put there is a check against your cert’s hash. This becomes a maintenance nightmare, so you are aware.
certificate.GetCertHashString();
Just so you know, letsencrypt is free, and you can generate new certs on demand if you script/program it on your web server. Otherwise, a long-term solution is a paid cert. With these options, you don’t need a code solution from your client, only the server.
Another option is to use Azure Application Proxy. We use a self-signed cert for reasons and was able to setup a limited proof-of-concept to get the Kinetic browser running. Since it has to come down and back from our on-prem server, there was a distinct reduction in performance - but it seemed to work. A REST service might not be so bad.
In general, AP receives requests in Azure and that cert is signed and public. A service runs on computers (in production, you’ll want redundancy) that open a connection back to the service. So, there are no firewall rules to worry about. A request comes into Azure, it forwards the request to one of the services running on-prem, the result is forwarded back to Azure. There’s a basic mapping function that changes the first part of your http request to point to an internal resource.
https://mycompany.com/api/getcommand
to
https://internalserver/api/getcommand
I do not agree, and here is why:
A self signed certificate is the same as a signed one, except it is verified by a trusted authority.
You are correct about the certificate error. I do not want to blindly trust it!!! I want to figure out the best
way to verify it myself. The risk assessment is to find out what I don’t know, and what I can do to address it. (There is always something you didn’t consider etc)
I didn’t plan to And you provided the clue my tired mind needed. Thanks @zachg
This is a one off solution, and if I need to I will do something different in the future if I need
to start doing a lot of different tasks with an API. I will probably buy a cert, but letsencrypt is awesome
for those that don’t want it.
I’m not sure I understand all that yet. (Need more coffee)
But that sounds like some good reading and maybe a good fit for some other things
I have going on at the plant. Thank you @Mark_Wonsil
All right then a cert is a cert is a cert it doesn’t matter if its legit or not it provides the same level of encryption. As long as you have a way to verify the request came from YOUR system and not somewhere else the validity of the certificate is irrelevant.
Particularly since you are the one doing the serving. If it were the other way around I’d be concerned that someone could trick you into connecting to the “wrong” endpoint.
But as I see it is “YOUR” Epicor instance connecting to “YOUR” Application hosted in “YOUR” server with a shitty cert… #WhoCares it is no less secure than anything else.
All a signed cert proves is that you are who indeed you say you are, and well you can always prove that to yourself in other ways.
PS: I feel like I need an explanation on this bit here
locked up tighter than Dick’s hat band
I’ve heard of “Locked tighter than a witches tit” before… which I also don’t get, but this one is a new one
