We have several customers who would like to keep IoT Edge device running for several months without restarting operation in their use cases.
The have already generated their own production certificates with 3-10 years lifetime.
Due to the documentation, we got to know that there's a auto generated certificate IoT Edge Hub Server certificate which always has a 90-day lifetime, but is automatically renewed before expiring. The auto_generated_ca_lifetime_days value doesn't affect this certificate.
Reference link:
https://learn.microsoft.com/en-us/azure/iot-edge/how-to-manage-device-certificates?view=iotedge-2018-06#customize-certificate-lifetime
If the IoT Edge hub server certificate was auto generated and auto renewed, do we have to regularly restart edgeHub to apply new certificate ? Or edgeHub will auto reload and apply new certificate?
If we have to restart it, how to deal with the use case that IoTEdge cannot be restarted for more than 90 days?
edgeHub server cert is automatically renewed. The container is restarted when renewal happens but no manual user intervention is required.
Related
Apple says:
On March 29, 2021, token and certificate-based HTTP/2 connections to the Apple Push Notification service must incorporate the new root certificate (AAACertificateServices 5/12/2020) which replaces the old GeoTrust Global CA root certificate. To ensure a seamless transition and to avoid push notification delivery failures, verify that both the old and new root certificates for the HTTP/2 interface are included in the Trust Store of each of your notification servers before March 29.
We want to verify that this won't break things for a Parse server running on Heroku. How would we go about this?
This is what we did – I'm not 100% confident about it, so let me know if I missed anything.
Via https://github.com/parse-community/node-apn/issues/49, we learned that Node uses its own list of root certs, independent of the underlying OS.
Then, we ran
heroku run "node -v" -a my-parse-installation
and found that it uses Node 15.8.0.
Then we checked https://github.com/nodejs/node/blob/v15.8.0/src/node_root_certs.h, confirming by searching for part of the certificate contents that it included both the new "AAA" cert and the old "GeoTrust" cert. (It did.)
We found both certs linked from https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/. So we looked there to know what to search for.
(Initially we tried stuff like curling to Apple's server from the Heroku server and were confused by the fact that it got errors, while push notifications via Parse still worked. But this is explained by the fact that Node uses its own certs per above.)
Can someone please ELI5 the difference between APN ssl certificate (sandbox) and APN ssl certificate (sandbox and production).
Apple uses different servers for sending push notifications to development versions and app store versions of the app. The development version is called Sandbox. The iOS maintains persistent connection to the its push servers depending on whether its development version or production version. Based on which certificate your app is signed (Dev or App Store/Ad Hoc) it will create a persistent connection to the respective push server. Since the two servers are different they will need different SSL certificates to establish a secure connection to the server.
For more info refer:
https://developer.apple.com/library/ios/technotes/tn2265/_index.html
We are running the Azure IoT Edge runtime on commodity servers inside a corporate intranet. I understand the Microsoft documentation recommends installing certificates for production IoT edge deployment.
We are using basic edge modules only, no gateway configurations, passthroughs, etc...
For our intranet scenario are self-signed certs suitable for production? If so can a single certificate be used for all devices?
Thanks
Yes, you can use self signed CA certificates. Check here.
Every IoT Edge device in production needs a device certificate authority (CA) certificate installed on it. That CA certificate is then declared to the IoT Edge runtime in the config.yaml file. For development and testing scenarios, the IoT Edge runtime creates temporary certificates if no certificates are declared in the config.yaml file. However, these temporary certificates expire after three months and aren't secure for production scenarios. For production scenarios, you should provide your own device CA certificate, either from a self-signed certificate authority or purchased from a commercial certificate authority.
Regarding using the same CA cert on various Edge devices,logically you should be able to use it as the identity cert is the one that differs for edge devices based on CN name.But I think you can easily check this out by doing the POC.
Here is the link to generate CA cert.
When using
docker login mycustomwebsite.com
I run into issue
x509: certificate has expired or is not yet valid
So, the certificate on mycustomwebsite.com is actually expired. I'm ok with that since I will update it later and right now I don't have access to it.
How can I tell docker & docker-compose to accept expired certificate?
Additionally, how can I completely disable certificate validation if necessary?
I've search SO for answers, closest was to use "--insecure-registry" but such option does not exist for my version or for versions 1.3.0+ (unless I'm completely confused with how insecure-registry was supposed to work)
ps:
Docker version 18.03.0-ce / Docker-compose version 1.20.1 / windows 7
ps2: didn't find solution that works, had to wait until I was able to renew certificates
I am trying to renew the O-Auth Certificate from one of the Front-end Server and I am facing some issues with it.
When using Lync Server 2013 deployment wizard to request O-Auth Certificate from Internal CA, the process goes well but at the end, the current certificate is not updated.
I can see the same certificate is replicated to other FEs (which is default behavior), it fails to apply to other FEs as well. I can see the following event logs in every FE's.
The replication of certificates from the central management store to the local machine failed due to a problem with certificate processing or installation on the local machine Microsoft Lync Server 2013, Replica Replicator Agent will continuously attempt
to retry the replication. While this condition persists, the certificates on the local machine will not be updated.
Exception: System.Security.Cryptography.CryptographicException: Access is denied.
at System.Security.Cryptography.X509Certificates.X509Store.RemoveCertificateFromStore(SafeCertStoreHandle safeCertStoreHandle, SafeCertContextHandle safeCertContext)
at Microsoft.Rtc.Management.Common.Certificates.CertUtils.AddCertificateToStore(X509Certificate2 cert, StoreName storeName, IManagementReporter reporter)
at Microsoft.Rtc.Management.Deployment.Core.Certificate.ImportFromPinnedArray(PinnedByteArray pfx, Boolean allowSelfSigned)
at Microsoft.Rtc.Management.Deployment.Core.Certificate.ReplicateCMSCertificates(IScopeAnchor scope)
at Microsoft.Rtc.Internal.Tools.Bootstrapper.Bootstrapper.ReplicateCMSCertificates().
Cause: The certificate provisioned in the central management store is invalid or cannot be handled on the local machine.
Resolution:
Ensure that certificates provisioned in the central management store are valid, have all needed issuer certificates included or installed on the local machine, and can be used with cryptographic providers available on the local machine.
I have checked the replication status and Replication is true.
Has anyone came across with similar situation.
I have read from another thread that this is due to the Root CA with private key. I have checked the server and I can see the Root CA with Private key. How can I remove private key from the Root CA only on the Lync Servers.
https://social.technet.microsoft.com/Forums/ie/en-US/47014b21-33d4-4a59-ba52-5cf537d14104/event-id-3039-lync-2013-internal-oauth-certificate?forum=lyncdeploy
Any help will be greatly appreciated.
I had a similar issue. Turned out the CA certificate on multiple front end servers certificate stores had a private key! Wrong on so many levels. Deleted all copies of CA cert with private key and copied again without, and then it all worked.