The IEC 62443-4-2 component requirement CR 1.9 "Strength of public key-based authentication" states:
For components that utilize public-key-based authentication, those
components shall provide directly or integrate into a system that
provides the capability within the same IACS environment to:
…
c) validate certificates by checking a given certificate’s revocation
status;
Which approach is used for certificate revocation for the TLS-encrypted communication with Azure IoT Hub: Online Certificate Status Protocol (OCSP) and/or Certificate Revocation Lists (CRLs)?
Is certificate revocation validation supported in the Azure IoT SDKs?
IoT Hub does not perform certificate revocation checks as of now. You need to explicitly disable devices to prevent them from connecting.
Related
I can't find any instructions on how to connect an IoT device to IoT Hub using X.509 CA cert with C SDK. There is a sample for C# SDK at https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-security-x509-get-started#register-x509-ca-certificates-to-your-iot-hub. The closest I can get for C-SDK is this API https://learn.microsoft.com/en-us/azure/iot-hub/iot-c-sdk-ref/iothub-device-client-h/iothubdeviceclient-createfromdeviceauth, but it didn't provide any doc on how to use it.
There is a sample code in https://github.com/Azure/azure-iot-sdk-c/tree/a698fa3fe9379b7a51a466e0a6b1fe5042db29c5/provisioning_client/samples/iothub_client_sample_hsm which seems imply on how to use this. But function call to IoTHubDeviceClient_CreateFromDeviceAuth() been comments out.
My goal is the to be able to connect downstream device to IoT Hub using X.509, with Edge been configured as transparent gateway. Since DPS provision to downstream device is not currently supported. downstream device can only connect to IoT Hub either using symmetric key, X.509 self-signed or X5.09 CA signed cert. Symmetric key or X.509 self signed is not an option as it require per device connection string which we are not able to provide in our IoT Device binary. X.509 CA signed cert approach seems works as all our device can preload with the cert, but I can't find any document how to archive this.
From the IoT hub side the language your device is using is irrelevant. Set it up as it suggests and then refer to this sample: https://github.com/Azure/azure-iot-sdk-c/blob/master/iothub_client/samples/iothub_ll_client_x509_sample/iothub_ll_client_x509_sample.c for an X.509 C client.
We are building an IoT architecture consisting of a API gateway and other services deployed on the cloud. The server uses a letsencrypt SSL certificate, so it is possible to communicate over SSL with the server. There are a number of hardware devices which send data to the server. We want to use x.509 certificate based communication and authentication from the devices to the server. I have two questions in this regard,
Is it possible to use letsencrypt certificate to generate the x.509 based certificate which can be configured on the device. If yes, what are the steps to do so
Since a letsencrypt certificate expires after 90 days, does it mean that after every 90 days, we will have to renew the certificates on all the devices? If yes, is there any best practice to handle such situations
Unfortunately, Let's Encrypt does not support intermediate certificates, so you wouldn't be able to generate your "own" certificates for your devices.
Currently I want to expose a gRPC Method as Public API and protected by Auth0 (JWT Token), with Istio(Envoy Proxy) will help validating the token on server side. Since the JWT Token is not encrypted by the standard (it is only used to end-user authentication and authorization layer), I want to encrypt the communication using TLS. Also, my public server already have valid certificate.
The problem is on the gRPC Client side. Every example I look, the gRPC Client have to initialize the TLS Connection with server cert pem file. Is it really necessary? Because it adds operational burden and complexity, where we have to distribute our server pem file everytime we renew the certificate AND/OR the client side has to restart the application.
Thanks,
Agung
If you are using a self signed certificate, then yes you must explicitly trust it in your client. If you use a publicly signed certificate on your Server, gRPC will use the Operating System's certificate authorities to verify the cert. (In the case of Java, it uses the JVMs cert authorities.)
If you are using a self-signed certificate you need to specify the server's root certificates in the pem_root_certs member of the SslCredentialsOptions struct passed in when creating a channel, as Carl says.
However if you are using a CA issued certificate, leaving the pem_root_certs member empty will cause gRPC to default to its own master list (reviewable online), not any OS-specific list.
What are the checks that will be performed when we call the method WL.Client.pinTrustedCertificatePublicKey for MobileFirst hybrid app ?
This is all explained in the documentation. See here: http://www.ibm.com/support/knowledgecenter/SSHSCD_7.1.0/com.ibm.worklight.dev.doc/monitor/c_cert_pinning_intro.html
Certificate pinning is the process of associating a host with its expected public key. Because you own both the server-side code and the client-side code, you can configure your client code to accept only a specific certificate for your domain name, instead of any certificate that corresponds to a trusted CA root certificate recognized by the operating system or browser.
A copy of the certificate is placed in your client application. During the SSL handshake (first request to the server), the IBM MobileFirst Platform Foundation for iOS client SDK verifies that the public key of the server certificate matches the public key of the certificate that is stored
in the app.
If pinning is successful, the public key inside the provided certificate is used to verify the integrity of the MobileFirst Server certificate during the secured request SSL/TLS handshake. If pinning fails, all SSL/TLS requests to the server are rejected by the client application.
The API initiates the pinning process.
I was reading an article about authenticating User with certificate to WCF service. Please correct me if I'm wrong. As per my understanding each user need a certificate to authenticate. How feasible is this in real world where, there are multiple clients? Is it good option to adopt?
Yes each user should have his own certificate. Certificate is used for encryption and signing (asymmetric security) and it can be used also for authentication. Authentication can be also provided by another supporting token but that is not supported by default WCF bindings (you must create your own).
To support such scenario you usually need your own certificate authority (CA) which will issue certificates to clients. It can be either use in corporate network where computers usually trusts corporate CA or it can be used over interned but CA's certificate must be issued by well known and trusted certificate authority (like VeriSign).
It is of course feasible in some scenarios. For example banks using client certificates plus some supporting token for connection to internet banking (that is usually web application scenario and not services but it is good B2C example). It is also sometimes used for communication among business partners (E2E / B2B).