I've read from here and here that every IoT Edge device in production needs a device certificate authority (CA) certificate installed on it. Otherwise the IoT Edge runtime will install a temporary certificate lasting 90 days, at the end of which the runtime must be restarted.
Since I've a lot of different edge devices to manage and it's unfeasible to do manual operations such as moving certificates inside each provisioned device and modifying manually the config.yaml file of the edge runtime, what can be done in order to proper set up production certificates automatically?
You need to provide the "production certificates" as explained here: Manage device certificates - Azure IoT Edge. If you have own CA, you can create the certificates and assign to the devices, if not, you will need to opt between use commercial certificates (initially recommended for production environments) or use self signed certificates. Currently there is an effort towards having a managed service (within DPS) to provide the certificate management, but is currently under development
To mention that either using commercial certificates or self-signed ones, you will need to take care of certificate rotation before the expiration (if using self-signed certs, you need to take care of the emission and custody).
Related
I have some difficulties to understand the difference between code signing and PKI.
Is it possible to use a PKI (with a hierarchy of CA) to issue certificate used to sign code source, and then use the revocation to invalid some software (for instance an old version that should not be used) ? Or are X.509 certificate incompatible with code signing and i'm missing something ?
Thanks your very much.
The PKI is an infrastructure that allows you to issue certificates with which you sign your binaries (among other things). You don't sign the source code.
You can create a separate certificate for every software release you have, however, I didn't see anybody use it this way and for that purpose.
Usually you enroll a few certificates and use them to sign all releases until they expire.
Even if a certificate does expire, it won't prevent from the customer keep using your software.
We are developing an IBM MobileFirst 7.1 Hybrid mobile application, and planning to use the certificate pinning feature.
We can find information on IBM website about the SSL certificate pinning on IBM MobileFirst website : Here is a post in the IBM Knowledge Center and Here is a tutorial and its sample project/code
All these resources are great, but I have some questions :
Are there any advantages to use native certificate pinning implementation for Android and iOS when my application is a hybrid application ?
If I use the hybrid environment code, will the SSL certificate be included in the wlapp, and then can be updated using direct update ?
Does the hybrid implementation of certificate pinning work on WindowsPhone 8 (Hybrid app for Silverlight environment) ?
In the tutorial video, I have seen that when SSL pinning is ON, and we call a URL outside our server (google for example) it will fail. Does this mean google maps will fail loading if I enable certificate pinning ?
What happen when the SSL certificate is revoked ?
What happen when the SSL certificate is expired ?
What is the best SSL renewal strategy to keep certificate pinning working and the application up while updating our server SSL certificate ?
Please advice
Are there any advantages to use native certificate pinning implementation for Android and iOS when my application is a hybrid application ?
You can always write your own code that does the pinning, or use 3rd party Cordova plug-ins. But none of those assure you the level of support you get by using the provided functionality. Note that you are then limited to the functionality provided (for example, certificate pinning by MobileFirst is restricted to a single destination host and not multiple).
If I use the hybrid environment code, will the SSL certificate be included in the wlapp, and then can be updated using direct update ?
You need to have the certificate in both the client and the server. You do not need to use Direct Update to update the certificate on the client.
The way it works is that you need to only update the certificate on the server, but you must maintain the same public key in case you do update it
Does the hybrid implementation of certificate pinning work on WindowsPhone 8 (Hybrid app for Silverlight environment) ?
As mentioned in the documentation, certificate pinning supports only: "native iOS, native Android, and hybrid iOS or hybrid Android"
In the tutorial video, I have seen that when SSL pinning is ON, and we call a URL outside our server (google for example) it will fail. Does this mean google maps will fail loading if I enable certificate pinning ?
The pinning relates only to requests that are bound to the MobileFirst Server and not to other services.
What happen when the SSL certificate is revoked ?
Requests that are bound to the MobileFirst Server will fail.
What happen when the SSL certificate is expired ?
Requests that are bound to the MobileFirst Server will fail.
What is the best SSL renewal strategy to keep certificate pinning working and the application up while updating our server SSL certificate ?
Because you only need to update the certificat eon the server, you only need to make sure to keep using the same public key as before.
I gather that most developers (except perhaps for larger companies) use self-signed certificates to sign their apk. Since this is required for app installation, the ability to sign your app is available to anyone. Fairly simple to use keytool and jarsigner from Java SDK. However these self-signed certs and associated private keys do NOT guarantee any degree of security unless you can somehow match that certificate with someone you actually trust. There is no ability to revocate these self-signed certificates (no CRL) and there is no "issuer" (since the certs are almost always self-signed) who "vouches" in some way for the identity of the certificate/key holder who signs the code.
So does Andriod platform have or plan to have any ability to prevent installation of apps SIGNED WITH A PARTICULAR SIGNATURE? or to enable settings only allowing installation of apps signed by a cert/key issued by a list of trusted CA (certificate-authorities/issuers) ?
However, there is some security available: In settings/Security you can prevent installation of anything (even signed and manually copied to your SIM) unless it comes from the Play Store, the default setting. Also you might be able to install a User certificate and ONLY allow apps signed by that cert to install (even if from the Play Store?).
I dont think the purpose of these certificates is to ensure an identity as a normal certificate signed by a CA would. As it seems to me the purpose of the certificates is just to have an extra security factor to ensure that the person that published the app for the first time is the one that publishes updates.
Without this someone that hacks your google account would be able to publish malicious updates to you entire user base.
So I would say its basically a two-factor authentication for publishing.
Is it acceptable practice to install an Authenticode code signing certificate directly on a build server to create a production signed build? I’m looking for some resources on the net that suggest or support that this practice is legitimate providing you’ve taken appropriate steps to secure the build server and the process by which a build is created and deployed.
All the “best practice” guidance I can find about code signing practices are way over the top in terms of suggested process. Microsoft’s reference document has as many as 6 servers in play for the simple act of signing a single assembly. http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/best_practices.doc
Some background:
My company creates simple rich-client line of business applications for its employees and direct customers. We do not create commercial software. My build server is physically secured and network secured using my companies strict security policies and procedures. Only very specific people in the organization have the ability to even start a build in my environment.
Our current process requires me to break a build/deploy process into many stages with a lot of manual process in place. We use physical devices to store the Authenticode certificates, requiring user-entered PINs to access. We have to shuffle the assemblies/manifests that require code signing to designated code signing PCs which also have to be physically secured.
To me, it is less secure to pass around a physical token/device and leave all these manual steps in place. There is nothing stopping a person with physical access to the token/device from signing anything they want. At least, with an automated, logged, controlled build server environment, you know what was signed and by who.
The main problem with installing a certificate on a build server and making it accessible to a build account, is that now any developer can sign any malicious piece of code by temporarily commiting it to some legitimate project, and reverting it back after the build.
No matter the actions are logged, the breach is hard to identify or prevent. Especially if development is active and several builds are done per day.
The only solution I can think of is to limit a number of people who can trigger an "RTM" build. Other build types may use a test certificate or avoid signing at all.
In fact, this is the question I bother my head too.
this is mostly a deployement than a programming question.
If I were to buy an SSL certificate from a CA, would I be able to use it to sign other applications (such as symbian, android, iphone ones)?
You need to get two different certificates. One to secure a server (https) and one to sign code. You can compare code signing certificates here
Server certificates (those that you'd use to enable HTTPS on a web server) are rarely enabled for code signing. I haven't looked at every CA in the world, and there probably are exceptions, but the more "legit" a CA is, the less likely they are to issue one certificate for both applications. In the end, I wouldn't expect to use the same certificate for both.
There is a better chance that a single code-signing certificate is accepted by most platforms. The developer documentation of each platform should list what CA certificates are built-in as trusted roots. In addition, most platforms will allow a user to view and modify the list.
You need to buy a certificate that is specifically authorized for code singing. In other words, the certificate must have the Extended Key Usage (EKU) for Code signing. Object ID (OID) for code signing can be found here
Most commercial CA's should be able to tell you which of their certificates have this.