%3CLINGO-SUB%20id%3D%22lingo-sub-1660386%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20IoT%20TLS%3A%20Changes%20are%20coming!%20(%E2%80%A6and%20why%20you%20should%20care)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1660386%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F765039%22%20target%3D%22_blank%22%3E%40RAMIoT%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHow%20will%20these%20change%20affect%20Microsoft%20Azure%20Sphere%20and%20Windows%20IOT%20Core%20devices%3F%26nbsp%3B%20Will%20those%20devices%20be%20automatically%20be%20updated%20with%20firmware%2FOS%20updates%20pushed%20out%20by%20Microsoft%2C%20assuming%20they%20have%20network%20connectivity%20back%20to%20the%20public%20internet%3F%26nbsp%3B%20%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1665832%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20IoT%20TLS%3A%20Changes%20are%20coming!%20(%E2%80%A6and%20why%20you%20should%20care)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1665832%22%20slang%3D%22en-US%22%3E%3CP%3EAzure%20Sphere%20utilizes%20the%20certificate%20provided%20in%20the%20Azure%20IoT%20C%20SDK%20that%20runs%20on%20Sphere.%20Since%20the%20%3CA%20href%3D%22https%3A%2F%2Fgithub.com%2FAzure%2Fazure-iot-sdk-c%2Fblob%2Fmaster%2Fcerts%2Fcerts.c%22%20target%3D%22_self%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3ESDK%20has%20the%20Baltimore%20root%3C%2FA%3E%2C%20this%20change%20should%20not%20impact%20default%20configurations%20of%20the%20Azure%20IoT%20C%20SDK%20on%20Sphere.%20However%2C%20if%20there%20have%20been%20intentional%20changes%20to%20include%20extra%20validation%20of%20ICAs%20or%20leaf%20certificates%2C%20some%20changes%20may%20be%20needed%20per%20the%20blog.%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3EFor%20Windows%20IoT%2C%20the%20cert%20store%20has%20the%20existing%20Baltimore%20root%20already.%20This%20is%20not%20changing.%20Of%20course%2C%20if%20there%20is%20code%20that%20performs%26nbsp%3Bextra%20validation%20of%20ICAs%20or%20leaf%20certificates%2C%20or%20if%20these%20have%20been%20pinned%2C%20then%20some%20changes%20may%20be%20needed.%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1667567%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20IoT%20TLS%3A%20Changes%20are%20coming!%20(%E2%80%A6and%20why%20you%20should%20care)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1667567%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F765039%22%20target%3D%22_blank%22%20rel%3D%22noopener%22%3E%40RAMIoT%3C%2FA%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3C%2FP%3E%3CP%3EWhat%20if%20we%20use%20only%20self-signed%20certificates%20with%20device%20SDK%20without%20pinned%20the%20Baltimore%20root%20CA%20explicitly%2C%20is%20it%20required%20any%20actions%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1681019%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20IoT%20TLS%3A%20Changes%20are%20coming!%20(%E2%80%A6and%20why%20you%20should%20care)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1681019%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F793904%22%20target%3D%22_blank%22%3E%40marusyk%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EI%20believe%20the%20flow%20you're%20talking%20about%20is%20for%20device%20authentication%20by%20the%20hub%20-%20devices%20can%20be%20provisioned%20with%20self%20signed%20certificates%20whose%20thumbprints%20are%20uploaded%20to%20hub%20so%20that%20hub%20can%20authenticate%20them.%20This%20flow%20is%20unchanged.%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3EWhat's%20changing%20is%20the%20way%20the%26nbsp%3B%3CEM%3Edevice%26nbsp%3B%3C%2FEM%3Eauthenticates%20the%20service%20through%20TLS.%20The%20server%20(IoT%20Hub%20or%20DPS)%20will%20present%20a%20SSL%20certificate%20rooted%20to%20Baltimore%20with%20different%20intermediate%20CAs%20starting%20Oct%205th.%20If%20you%20are%20using%20the%20default%20C%20device%20SDK%2C%20the%20Baltimore%20root%20is%20pinned%2C%20and%20you%20should%20be%20okay.%20If%20you%20have%20performed%20any%20extra%20validation%20against%20any%20certificate%20that%20is%26nbsp%3B%3CU%3Enot%3C%2FU%3E%26nbsp%3Bthe%20Baltimore%20root%2C%20you%20may%20need%20to%20update%20that%20code.%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EHope%20this%20helps!%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1699912%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20IoT%20TLS%3A%20Changes%20are%20coming!%20(%E2%80%A6and%20why%20you%20should%20care)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1699912%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F765039%22%20target%3D%22_blank%22%3E%40RAMIoT%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20are%20using%20self%20signed%20certificate%20to%20provision%20devices%20into%20iot%20hub.%26nbsp%3BOur%20Device%20is%20provisioning%20to%20IoT%20Hub%20via%20Azure%20DPS.%20We%20had%20Azure%20Device%20SDK%20on%20Device%20which%20connect%20to%20DPS%20using%20global%20endpoint%20%22global.azure-devices-provisioning.net%22%2C%20ID%20Scope%2C%20and%20device%20certificates%20X.509%20(Created%20using%20Self%20Signed%20Certificate).%20Once%20Device%20is%20provisioned%20on%20Azure%20IoT%20Hub%20using%20DPS%2C%20device%20will%20start%20communicating%20to%20IoT%20hub%20using%20device%20certificates%20X.509%20and%20Device%20ID.%20We%20hadn't%20pinned%20certificates%20on%20device.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSTRONG%3EDoes%20is%20there%20any%20impact%20based%20on%20above%20implementation%20approach%3F%3C%2FSTRONG%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20also%20tried%20to%20connect%20to%20DPS%20using%20test%20environment%20provided%20by%20Azure%20in%20this%20blog.%20We%20used%20our%20existing%20device%20valid%20certificates%20which%20are%20chaining%20to%20self%20signed%20root%20certificate%20and%20try%20to%20connect%20with%20below%20endpoints.%20But%20we%20are%20getting%20error%20code%20401002.%20Below%20is%20the%20response%20which%20we%20got.%3C%2FP%3E%3CDIV%3E%7B%22errorCode%22%3A401002%2C%22trackingId%22%3A%22****************************%22%2C%22message%22%3A%22Invalid%20certificate.%22%2C%22timestampUtc%22%3A%222020-09-22T16%3A26%3A59.3100404Z%22%7D%3C%2FDIV%3E%3CUL%3E%3CLI%3EAzure%20Test%20Environment%3CUL%3E%3CLI%3EGlobal%20Service%20Endpoint%3A%20global-canary.azure-devices-provisioning.net%3C%2FLI%3E%3CLI%3EID%20SCOPE%3A%200ne0017FD54%3C%2FLI%3E%3C%2FUL%3E%3C%2FLI%3E%3C%2FUL%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSTRONG%3EWhat%20steps%20we%20need%20to%20follow%20to%20prevent%20disconnection%20of%20devices%20from%20azure%3F%3C%2FSTRONG%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThanks%2C%3C%2FP%3E%3CP%3ERajan%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1699966%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20IoT%20TLS%3A%20Changes%20are%20coming!%20(%E2%80%A6and%20why%20you%20should%20care)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1699966%22%20slang%3D%22en-US%22%3E%3CP%3EHi%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F803848%22%20target%3D%22_blank%22%3E%40rajanpatel%3C%2FA%3E%2C%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThe%20flow%20you're%20referring%20to%20is%20how%20IoT%20Hub%20authenticates%20devices%3B%20there%20are%203%20methods%20-%20Symmetric%20Key%2C%20X.509%20self%20signed%2C%20and%20X.509%20CA.%20These%20flows%20are%20%3CSTRONG%3Enot%3C%2FSTRONG%3E%20impacted.%20The%20TLS%26nbsp%3B%3CEM%3EServer%26nbsp%3B%3C%2FEM%3ECertificates%20of%20Hub%20and%20DPS%20are%20changing%20and%20hence%20impacted.%20This%20means%20that%20when%20establishing%20a%20TLS%20connection%20with%20the%20IoT%20Hub%20or%20global%20DPS%20endpoint%2C%20the%26nbsp%3B%3CEM%3Edevice%26nbsp%3B%3C%2FEM%3Emust%20validate%20the%20server%20by%20looking%20up%20at%20the%20root%20chain%20and%20validating%20that%20the%20root%20certificate%20(in%20this%20case%20'Baltimore%20Cyber%20Trust%20Root')%20is%20indeed%20a%20trusted%20CA%20on%20the%20device.%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3EThe%20error%20you%20are%20receiving%20is%20because%20the%20test%20DPS%20instance%20does%20not%20have%20your%20device%20enrolled.%20If%20you'd%20like%20to%20test%20that%2C%20please%20open%20a%20support%20ticket%20as%20described%20in%20the%20Support%20section%20above%2C%20and%20our%20support%20team%20will%20be%20happy%20to%20enroll%20your%20device%20and%20allow%20you%20to%20perform%20an%20end%20to%20end%20test.%20If%20you're%20able%20to%20independently%20test%20that%20you're%20able%20to%20establish%20a%20TLS%20connection%20using%20%3CA%20href%3D%22https%3A%2F%2Fsourceforge.net%2Fprojects%2Fwireshare%2F%22%20target%3D%22_self%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ewireshark%3C%2FA%3E%26nbsp%3Bthen%20that's%20the%20only%20validation%20required.%20Hope%20this%20helps!%20%3A)%3C%2Fimg%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1736745%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20IoT%20TLS%3A%20Changes%20are%20coming!%20(%E2%80%A6and%20why%20you%20should%20care)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1736745%22%20slang%3D%22en-US%22%3E%3CP%3EI%20am%20using%20IoT%20DPS%20and%20IoT%20Hub%20from%20Linux%20VM%20%2B%20IoT%20Python%20SDK.%20My%20understanding%20is%20that%20I%20am%20not%20impacted%20based%20on%20input%20which%20you%20provided%3A%3C%2FP%3E%3CP%3E%22If%20your%20devices%20depend%20on%20the%20operating%20system%20certificate%20store%20for%20getting%20these%20roots%20or%20use%20the%20device%2Fgateway%20SDKs%20as%20provided%2C%20then%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CSTRONG%3E%3CFONT%20color%3D%22%23008000%22%3Eno%20action%20is%20required%3C%2FFONT%3E.%22%3C%2FSTRONG%3E%3C%2FP%3E%3CP%3EIn%20addition%20I%20did%20following%20test%20with%20curl%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CPRE%3E%5Badmin%40node01%20~%5D%24%20curl%20-v%20https%3A%2F%2Fglobal-canary.azure-devices-provisioning.net%3A8883%0A*%20About%20to%20connect()%20to%20global-canary.azure-devices-provisioning.net%20port%208883%20(%230)%0A*%20%20%20Trying%2052.225.179.220...%0A*%20Connected%20to%20global-canary.azure-devices-provisioning.net%20(52.225.179.220)%20port%208883%20(%230)%0A*%20Initializing%20NSS%20with%20certpath%3A%20sql%3A%2Fetc%2Fpki%2Fnssdb%0A*%20%20%20CAfile%3A%20%2Fetc%2Fpki%2Ftls%2Fcerts%2Fca-bundle.crt%0A%20%20CApath%3A%20none%0A*%20NSS%3A%20client%20certificate%20not%20found%20(nickname%20not%20specified)%0A*%20SSL%20connection%20using%20TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256%0A*%20Server%20certificate%3A%0A*%20%20%20%20%20%20%20subject%3A%20CN%3D*.azure-devices-provisioning.net%0A*%20%20%20%20%20%20%20start%20date%3A%20Sep%2008%2021%3A29%3A05%202020%20GMT%0A*%20%20%20%20%20%20%20expire%20date%3A%20Sep%2008%2021%3A29%3A05%202021%20GMT%0A*%20%20%20%20%20%20%20common%20name%3A%20*.azure-devices-provisioning.net%0A*%20%20%20%20%20%20%20issuer%3A%20CN%3DMicrosoft%20RSA%20TLS%20CA%2001%2CO%3DMicrosoft%20Corporation%2CC%3DUS%0A%26gt%3B%20GET%20%2F%20HTTP%2F1.1%0A%26gt%3B%20User-Agent%3A%20curl%2F7.29.0%0A%26gt%3B%20Host%3A%20global-canary.azure-devices-provisioning.net%3A8883%0A%26gt%3B%20Accept%3A%20*%2F*%0A%26gt%3B%0A*%20Empty%20reply%20from%20server%0A*%20Connection%20%230%20to%20host%20global-canary.azure-devices-provisioning.net%20left%20intact%0Acurl%3A%20(52)%20NSS%3A%20client%20certificate%20not%20found%20(nickname%20not%20specified)%0A%5Badmin%40node01%20~%5D%24%20curl%20-v%20https%3A%2F%2Fsdk-cert-test.azure-devices.net%3A8883%0A*%20About%20to%20connect()%20to%20sdk-cert-test.azure-devices.net%20port%208883%20(%230)%0A*%20%20%20Trying%2052.180.177.125...%0A*%20Connected%20to%20sdk-cert-test.azure-devices.net%20(52.180.177.125)%20port%208883%20(%230)%0A*%20Initializing%20NSS%20with%20certpath%3A%20sql%3A%2Fetc%2Fpki%2Fnssdb%0A*%20%20%20CAfile%3A%20%2Fetc%2Fpki%2Ftls%2Fcerts%2Fca-bundle.crt%0A%20%20CApath%3A%20none%0A*%20NSS%3A%20client%20certificate%20not%20found%20(nickname%20not%20specified)%0A*%20SSL%20connection%20using%20TLS_DHE_RSA_WITH_AES_256_GCM_SHA384%0A*%20Server%20certificate%3A%0A*%20%20%20%20%20%20%20subject%3A%20CN%3D*.azure-devices.net%0A*%20%20%20%20%20%20%20start%20date%3A%20Sep%2010%2021%3A15%3A38%202020%20GMT%0A*%20%20%20%20%20%20%20expire%20date%3A%20Sep%2010%2021%3A15%3A38%202021%20GMT%0A*%20%20%20%20%20%20%20common%20name%3A%20*.azure-devices.net%0A*%20%20%20%20%20%20%20issuer%3A%20CN%3DMicrosoft%20RSA%20TLS%20CA%2001%2CO%3DMicrosoft%20Corporation%2CC%3DUS%0A%26gt%3B%20GET%20%2F%20HTTP%2F1.1%0A%26gt%3B%20User-Agent%3A%20curl%2F7.29.0%0A%26gt%3B%20Host%3A%20sdk-cert-test.azure-devices.net%3A8883%0A%26gt%3B%20Accept%3A%20*%2F*%0A%26gt%3B%0A*%20Empty%20reply%20from%20server%0A*%20Connection%20%230%20to%20host%20sdk-cert-test.azure-devices.net%20left%20intact%0Acurl%3A%20(52)%20NSS%3A%20client%20certificate%20not%20found%20(nickname%20not%20specified)%0A%5Badmin%40node01%20~%5D%24%3C%2FPRE%3E%3CP%3EIn%20case%20of%20issues%20with%20validation%20of%20the%20server%20certificate%2C%20curl%20reports%20it%20and%20%22-k%2C%20--insecure%22%20option%20is%20needed%20to%20skip%20validation%20of%20the%20server%20cert.%3C%2FP%3E%3CP%3EDoes%20the%20above%20test%20confirm%20that%20I%20will%20not%20be%20impacted%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThanks%2C%3C%2FP%3E%3CP%3ELeszek%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1658456%22%20slang%3D%22en-US%22%3EAzure%20IoT%20TLS%3A%20Changes%20are%20coming!%20(%E2%80%A6and%20why%20you%20should%20care)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1658456%22%20slang%3D%22en-US%22%3E%3CP%3EMicrosoft%20is%20updating%20Azure%20services%20in%20a%20phased%20manner%20to%20use%20TLS%20server%20certificates%20from%20a%20different%20set%20of%20Certificate%20Authorities%20(CAs)%20beginning%20August%2013%2C%202020%20and%20concluding%20approximately%20on%20October%2026%2C%202020.%20%3CSTRONG%3EWe%20expect%20that%20most%20Azure%20IoT%20customers%20that%20interact%20with%20IoT%20Hub%20and%20DPS%20will%20not%20be%20impacted%3B%20however%2C%20your%20application%20%3C%2FSTRONG%3E%3CSTRONG%3Emay%20be%20impacted%20%3C%2FSTRONG%3E%3CSTRONG%3Eif%20you%20explicitly%20specify%20a%20list%20of%20acceptable%20CAs%20(a%20practice%20known%20as%20%E2%80%9Ccertificate%20pinning%E2%80%9D)%3C%2FSTRONG%3E.%20This%20change%20is%20limited%20to%20services%20in%20%3CA%20href%3D%22https%3A%2F%2Fazure.microsoft.com%2Fen-us%2Fregions%2F%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3Epublic%20Azure%20cloud%3C%2FA%3E%20and%20no%20sovereign%20cloud%20like%20%3CA%20href%3D%22https%3A%2F%2Fazure.cn%2F%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3EAzure%20China%3C%2FA%3E.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThis%20change%20is%20being%20made%20because%20the%20current%20CA%20certificates%20%3CA%20href%3D%22https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1649951%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Edo%20not%20comply%20with%20one%20of%20the%20CA%2FBrowser%20Forum%20Baseline%20requirements%3C%2FA%3E.%20This%20was%20reported%20on%20July%201%2C%202020%20and%20impacts%20multiple%20popular%20Public%20Key%20Infrastructure%20(PKI)%20providers%20worldwide.%20Today%2C%20most%20of%20the%20TLS%20certificates%20used%20by%20Azure%20services%20are%20issued%20from%20the%20%22Baltimore%20CyberTrust%20Root%22%20PKI.%3C%2FP%3E%0A%3CP%3EThe%20following%20services%20used%20by%20Azure%20IoT%20devices%20will%20remain%20chained%20to%20the%20Baltimore%20CyberTrust%20Root*%2C%20but%20their%20TLS%20%3CEM%3E%3CSTRONG%3Eserver%3C%2FSTRONG%3E%20%3C%2FEM%3Ecertificates%20will%20be%20issued%20by%20new%20Intermediate%20Certificate%20Authorities%20(ICAs)%20%3CSTRONG%3Estarting%20October%205%2C%202020%20progressing%20regionally%20through%20the%20month%20on%20a%20measured%20deployment%20schedule%3C%2FSTRONG%3E%3A%3C%2FP%3E%0A%3COL%3E%0A%3CLI%3EAzure%20IoT%20Hub%3C%2FLI%3E%0A%3CLI%3EAzure%20IoT%20Hub%20Device%20Provisioning%20Service%20(DPS)%3C%2FLI%3E%0A%3CLI%3EAzure%20Storage%20Services%3C%2FLI%3E%0A%3C%2FOL%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSTRONG%3EIf%20any%20client%20application%20or%20device%20has%20pinned%20to%20an%20Intermediate%20CA%20or%20leaf%20certificate%3C%2FSTRONG%3E%20rather%20than%20the%20Baltimore%20CyberTrust%20Root%2C%20%3CFONT%20color%3D%22%23FF0000%22%3E%3CSTRONG%3Eimmediate%20action%20is%20required%3C%2FSTRONG%3E%20%3C%2FFONT%3Eto%20prevent%20disruption%20of%20IoT%20device%20connectivity%20to%20Azure.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CEM%3E*%3C%2FEM%3E%20%3CEM%3EOther%20Azure%20service%20TLS%20certificates%20may%20be%20issued%20by%20a%20different%20PKI.%3C%2FEM%3E%3C%2FP%3E%0A%3CP%3E%3CEM%3E%26nbsp%3B%3C%2FEM%3E%3C%2FP%3E%0A%3CH2%20id%3D%22toc-hId--1268460662%22%20id%3D%22toc-hId--1268460688%22%3ECertificate%20Renewal%20Summary%3C%2FH2%3E%0A%3CP%3EThe%20table%20below%20provides%20information%20about%20the%20certificates%20that%20are%20being%20rolled.%20Depending%20on%20which%20certificate%20your%20device%20or%20gateway%20clients%20use%20for%20establishing%20TLS%20connections%2C%20action%20may%20be%20needed%20to%20prevent%20loss%20of%20connectivity.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CTABLE%20width%3D%22100%25%22%3E%0A%3CTBODY%3E%0A%3CTR%3E%0A%3CTD%20width%3D%2210%25%22%3E%3CP%3E%3CSTRONG%3ECertificate%3C%2FSTRONG%3E%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20width%3D%2240%25%22%3E%3CP%3E%3CSTRONG%3ECurrent%3C%2FSTRONG%3E%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20width%3D%2240%25%22%3E%3CP%3E%3CSTRONG%3EPost%20Rollover%20(Oct%205%2C%202020)%3C%2FSTRONG%3E%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20width%3D%2210%25%22%3E%3CP%3E%3CSTRONG%3EAction%3C%2FSTRONG%3E%3C%2FP%3E%0A%3C%2FTD%3E%0A%3C%2FTR%3E%0A%3CTR%3E%0A%3CTD%20width%3D%2210%25%22%3E%3CP%3ERoot%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20width%3D%2240%25%22%3E%3CP%3EThumbprint%3A%20d4de20d05e66fc53fe1a50882c78db2852cae474%3CBR%20%2F%3EExpiration%3A%20Monday%2C%20May%2012%2C%202025%2C%204%3A59%3A00%20PM%3CBR%20%2F%3ESubject%20Name%3A%3CBR%20%2F%3ECN%20%3D%20Baltimore%20CyberTrust%20Root%3C%2FP%3E%0A%3CP%3EOU%20%3D%20CyberTrust%3CBR%20%2F%3EO%20%3D%20Baltimore%3CBR%20%2F%3EC%20%3D%20IE%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20width%3D%2240%25%22%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ENot%20Changing%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20width%3D%2240%25%22%20style%3D%22background-color%3A%20%2373ad4c%3B%22%3E%3CP%3E%3CSTRONG%3ENone%3C%2FSTRONG%3E%3C%2FP%3E%0A%3C%2FTD%3E%0A%3C%2FTR%3E%0A%3CTR%3E%0A%3CTD%20width%3D%2210%25%22%3E%3CP%3EIntermediates%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20width%3D%2240%25%22%3E%3CP%3E%3CU%3EThumbprints%3A%3C%2FU%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ECN%20%3D%20Microsoft%20IT%20TLS%20CA%201%3C%2FP%3E%0A%3CP%3EThumbprint%3A%20417e225037fbfaa4f95761d5ae729e1aea7e3a42%3C%2FP%3E%0A%3CP%3E----------------------------------------------------%3C%2FP%3E%0A%3CP%3ECN%20%3D%20Microsoft%20IT%20TLS%20CA%202%3C%2FP%3E%0A%3CP%3EThumbprint%3A%2054d9d20239080c32316ed9ff980a48988f4adf2d%3C%2FP%3E%0A%3CP%3E----------------------------------------------------%3C%2FP%3E%0A%3CP%3ECN%20%3D%20Microsoft%20IT%20TLS%20CA%204%3C%2FP%3E%0A%3CP%3EThumbprint%3A%208a38755d0996823fe8fa3116a277ce446eac4e99%3C%2FP%3E%0A%3CP%3E----------------------------------------------------%3C%2FP%3E%0A%3CP%3ECN%20%3D%20Microsoft%20IT%20TLS%20CA%205%3C%2FP%3E%0A%3CP%3EThumbprint%3A%20Ad898ac73df333eb60ac1f5fc6c4b2219ddb79b7%3C%2FP%3E%0A%3CP%3E----------------------------------------------------%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EExpiration%3A%20%E2%80%8EFriday%2C%20%E2%80%8EMay%20%E2%80%8E20%2C%20%E2%80%8E2024%205%3A52%3A38%20AM%3CBR%20%2F%3ESubject%20Name%3A%3C%2FP%3E%0A%3CP%3EOU%20%3D%20Microsoft%20IT%3C%2FP%3E%0A%3CP%3EO%20%3D%20Microsoft%20Corporation%3C%2FP%3E%0A%3CP%3EL%20%3D%20Redmond%3C%2FP%3E%0A%3CP%3ES%20%3D%20Washington%3C%2FP%3E%0A%3CP%3EC%20%3D%20US%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20width%3D%2240%25%22%3E%3CP%3E%3CU%3EThumbprints%3A%20%3C%2FU%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ECN%20%3D%20Microsoft%20RSA%20TLS%20CA%2001%3C%2FP%3E%0A%3CP%3EThumbprint%3A%20703d7a8f0ebf55aaa59f98eaf4a206004eb2516a%26nbsp%3B%26nbsp%3B%26nbsp%3B%3C%2FP%3E%0A%3CP%3E----------------------------------------------------%3C%2FP%3E%0A%3CP%3ECN%20%3D%20Microsoft%20RSA%20TLS%20CA%2002%3C%2FP%3E%0A%3CP%3EThumbprint%3A%20b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75%3C%2FP%3E%0A%3CP%3E----------------------------------------------------%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EExpiration%3A%20%E2%80%8ETuesday%2C%20%E2%80%8EOctober%20%E2%80%8E8%2C%20%E2%80%8E2024%2012%3A00%3A00%20AM%3B%20%3CBR%20%2F%3ESubject%20Name%3A%3C%2FP%3E%0A%3CP%3EO%20%3D%20Microsoft%20Corporation%3C%2FP%3E%0A%3CP%3EC%20%3D%20US%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20width%3D%2210%25%22%20style%3D%22background-color%3A%20%23d30f0f%3B%22%3E%3CP%3E%3CSTRONG%3ERequired%3C%2FSTRONG%3E%3C%2FP%3E%0A%3C%2FTD%3E%0A%3C%2FTR%3E%0A%3CTR%3E%0A%3CTD%20width%3D%2210%25%22%3E%3CP%3ELeaf%20(IoT%20Hub)%3CBR%20%2F%3E%26nbsp%3B%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20width%3D%2240%25%22%3E%3CP%3EThumbprint%3A%208b1a359705188c5577cb2dcd9a06331807c0bb97%3CBR%20%2F%3EExpiration%3A%20%E2%80%8EFriday%2C%20%E2%80%8EMarch%20%E2%80%8E19%2C%20%E2%80%8E2021%206%3A15%3A48%20PM%3C%2FP%3E%0A%3CP%3ESubject%20Name%3A%3C%2FP%3E%0A%3CP%3ECN%20%3D%20*.azure-devices.net%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20width%3D%2240%25%22%3E%3CP%3EThumbprint%3A%20Varies%3CBR%20%2F%3EExpiration%3A%20Varies%3CBR%20%2F%3ESubject%20Name%3A%20%3CBR%20%2F%3ECN%20%3D%20*.azure-devices.net%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20width%3D%2210%25%22%20style%3D%22background-color%3A%20%23d30f0f%3B%22%3E%3CP%3E%3CSTRONG%3ERequired%3C%2FSTRONG%3E%3C%2FP%3E%0A%3C%2FTD%3E%0A%3C%2FTR%3E%0A%3CTR%3E%0A%3CTD%20width%3D%2210%25%22%3E%3CP%3ELeaf%20(DPS)%3CBR%20%2F%3E%26nbsp%3B%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20width%3D%2240%25%22%3E%3CP%3EThumbprint%3A%20f568f692f3274ecbb479c94272d6f3344a3f0247%3CBR%20%2F%3EExpiration%3A%20%E2%80%8EFriday%2C%20%E2%80%8EMarch%20%E2%80%8E19%2C%20%E2%80%8E2021%205%3A58%3A35%20PM%3C%2FP%3E%0A%3CP%3ESubject%20Name%3A%3C%2FP%3E%0A%3CP%3ECN%20%3D%20*.azure-devices-provisioning.net%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20width%3D%2240%25%22%3E%3CP%3EThumbprint%3A%20Varies%3CBR%20%2F%3EExpiration%3A%20Varies%3CBR%20%2F%3ESubject%20Name%3A%20%3CBR%20%2F%3ECN%20%3D%20*.azure-devices-provisioning.net%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20width%3D%2210%25%22%20style%3D%22background-color%3A%20%23d30f0f%3B%22%3E%3CP%3E%3CSTRONG%3ERequired%3C%2FSTRONG%3E%3C%2FP%3E%0A%3C%2FTD%3E%0A%3C%2FTR%3E%0A%3C%2FTBODY%3E%0A%3C%2FTABLE%3E%0A%3CP%3ENote%3A%20Both%20the%20intermediate%20and%20leaf%20certificates%20are%20expected%20to%20change%20frequently.%20We%20recommend%20not%20taking%20dependencies%20on%20them%20and%20instead%20pinning%20the%20root%20certificate%20as%20it%20rolls%20less%20frequently.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CH2%20id%3D%22toc-hId-1219052171%22%20id%3D%22toc-hId-1219052145%22%3EAction%20Required%3C%2FH2%3E%0A%3COL%3E%0A%3CLI%3EIf%20your%20devices%20depend%20on%20the%20operating%20system%20certificate%20store%20for%20getting%20these%20roots%20or%20use%20the%20device%2Fgateway%20SDKs%20as%20provided%2C%20then%20%3CSTRONG%3E%3CFONT%20color%3D%22%23008000%22%3Eno%20action%20is%20required%3C%2FFONT%3E.%20%3C%2FSTRONG%3E%3C%2FLI%3E%0A%3CLI%3EIf%20your%20devices%20pin%20the%20Baltimore%20root%20CA%20among%20others%2C%20then%20%3CFONT%20color%3D%22%23008000%22%3E%3CSTRONG%3Eno%20action%20is%20required%3C%2FSTRONG%3E%3C%2FFONT%3E%20related%20to%20this%20change.%3COL%20class%3D%22lia-list-style-type-lower-alpha%22%3E%0A%3CLI%3EIf%20your%20device%20interacts%20with%20other%20Azure%20services%20(e.g.%20IoT%20Edge%20-%26gt%3B%20Microsoft%20Container%20Registry%20or%20Device%20-%26gt%3B%20Azure%20API%20Gateway)%2C%20then%20%3CSTRONG%3E%3CFONT%20color%3D%22%23FF0000%22%3Eyou%20must%20pin%20additional%20roots%3C%2FFONT%3E%3C%2FSTRONG%3E%20as%20provided%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fkey-vault%2Fgeneral%2Fwhats-new%23azure-tls-certificate-changes%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehere%3C%2FA%3E.%3C%2FLI%3E%0A%3C%2FOL%3E%0A%3C%2FLI%3E%0A%3CLI%3EIf%20your%20devices%20use%20a%20connection%20stack%20other%20than%20the%20ones%20provided%20in%20an%20Azure%20IoT%20SDK%2C%20and%20pin%20any%20intermediary%20or%20leaf%20TLS%20certificates%20instead%20of%20the%20Baltimore%20root%20CA%2C%20then%20%3CFONT%20color%3D%22%23FF0000%22%3E%3CSTRONG%3Eimmediate%20action%20is%20required%3A%3C%2FSTRONG%3E%3C%2FFONT%3E%3COL%20class%3D%22lia-list-style-type-lower-alpha%22%3E%0A%3CLI%3ETo%20continue%20without%20disruption%20due%20to%20this%20change%2C%20Microsoft%20recommends%20that%20client%20applications%20or%20devices%20pin%20the%20Baltimore%20root%20-%3COL%20class%3D%22lia-list-style-type-lower-roman%22%3E%0A%3CLI%3E%3CA%20href%3D%22https%3A%2F%2Fcacerts.digicert.com%2FBaltimoreCyberTrustRoot.crt%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3EBaltimore%20Root%20CA%3C%2FA%3E%20%3CBR%20%2F%3E(Thumbprint%3A%20d4de20d05e66fc53fe1a50882c78db2852cae474)%3C%2FLI%3E%0A%3CLI%3ETo%20prevent%20future%20disruption%2C%20client%20applications%20or%20devices%20should%20also%20pin%20the%20following%20roots%3A%3COL%20class%3D%22lia-list-style-type-upper-alpha%22%3E%0A%3CLI%3E%3CA%20href%3D%22http%3A%2F%2Fwww.microsoft.com%2Fpkiops%2Fcerts%2FMicrosoft%2520RSA%2520Root%2520Certificate%2520Authority%25202017.crt%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3EMicrosoft%20RSA%20Root%20Certificate%20Authority%202017%3C%2FA%3E%3CBR%20%2F%3E(Thumbprint%3A%2073a5e64a3bff8316ff0edccc618a906e4eae4d74)%3C%2FLI%3E%0A%3CLI%3E%3CA%20href%3D%22https%3A%2F%2Fcacerts.digicert.com%2FDigiCertGlobalRootG2.crt%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3EDigicert%20Global%20Root%20G2%3C%2FA%3E%20%3CBR%20%2F%3E(Thumbprint%3A%20df3c24f9bfd666761b268073fe06d1cc8d4f82a4)%3C%2FLI%3E%0A%3C%2FOL%3E%0A%3C%2FLI%3E%0A%3C%2FOL%3E%0A%3C%2FLI%3E%0A%3CLI%3ETo%20continue%20pinning%20intermediaries%2C%20replace%20the%20existing%20certificates%20with%20the%20new%20intermediates%20CAs%3A%3COL%20class%3D%22lia-list-style-type-lower-roman%22%3E%0A%3CLI%3E%3CA%20href%3D%22http%3A%2F%2Fwww.microsoft.com%2Fpki%2Fmscorp%2FMicrosoft%2520RSA%2520TLS%2520CA%252001.crt%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3EMicrosoft%20RSA%20TLS%20CA%2001%3C%2FA%3E%20%3CBR%20%2F%3E(Thumbprint%3A%20703d7a8f0ebf55aaa59f98eaf4a206004eb2516a)%3C%2FLI%3E%0A%3CLI%3E%3CA%20href%3D%22http%3A%2F%2Fwww.microsoft.com%2Fpki%2Fmscorp%2FMicrosoft%2520RSA%2520TLS%2520CA%252002.crt%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3EMicrosoft%20RSA%20TLS%20CA%2002%3C%2FA%3E%20%3CBR%20%2F%3E(Thumbprint%3A%20b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75)%3C%2FLI%3E%0A%3CLI%3ETo%20minimize%20future%20code%20changes%2C%20also%20pin%20the%20following%20ICAs%3A%3COL%20class%3D%22lia-list-style-type-upper-alpha%22%3E%0A%3CLI%3E%3CA%20href%3D%22https%3A%2F%2Fwww.microsoft.com%2Fpkiops%2Fcerts%2FMicrosoft%2520Azure%2520TLS%2520Issuing%2520CA%252001.cer%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3EMicrosoft%20Azure%20TLS%20Issuing%20CA%2001%3C%2FA%3E%3CBR%20%2F%3E(Thumbprint%3A%202f2877c5d778c31e0f29c7e371df5471bd673173)%3C%2FLI%3E%0A%3CLI%3E%3CA%20href%3D%22https%3A%2F%2Fwww.microsoft.com%2Fpkiops%2Fcerts%2FMicrosoft%2520Azure%2520TLS%2520Issuing%2520CA%252002.cer%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3EMicrosoft%20Azure%20TLS%20Issuing%20CA%2002%3C%2FA%3E%3CBR%20%2F%3E(Thumbprint%3A%20e7eea674ca718e3befd90858e09f8372ad0ae2aa)%3C%2FLI%3E%0A%3CLI%3E%3CA%20href%3D%22https%3A%2F%2Fwww.microsoft.com%2Fpkiops%2Fcerts%2FMicrosoft%2520Azure%2520TLS%2520Issuing%2520CA%252005.cer%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3EMicrosoft%20Azure%20TLS%20Issuing%20CA%2005%3C%2FA%3E%3CBR%20%2F%3E(Thumbprint%3A%206c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5)%3C%2FLI%3E%0A%3CLI%3E%3CA%20href%3D%22https%3A%2F%2Fwww.microsoft.com%2Fpkiops%2Fcerts%2FMicrosoft%2520Azure%2520TLS%2520Issuing%2520CA%252006.cer%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3EMicrosoft%20Azure%20TLS%20Issuing%20CA%2006%3C%2FA%3E%3CBR%20%2F%3E(Thumbprint%3A%2030e01761ab97e59a06b41ef20af6f2de7ef4f7b0)%3C%2FLI%3E%0A%3C%2FOL%3E%0A%3C%2FLI%3E%0A%3C%2FOL%3E%0A%3C%2FLI%3E%0A%3C%2FOL%3E%0A%3C%2FLI%3E%0A%3C%2FOL%3E%0A%3COL%20start%3D%224%22%3E%0A%3CLI%3EIf%20your%20client%20applications%2C%20devices%2C%20or%20networking%20infrastructure%20(e.g.%20firewalls)%20perform%20any%20sub%20root%20validation%20in%20code%2C%20%3CFONT%20color%3D%22%23FF0000%22%3E%3CSTRONG%3Eimmediate%20action%20is%20required%3A%3C%2FSTRONG%3E%3C%2FFONT%3E%3COL%20class%3D%22lia-list-style-type-lower-alpha%22%3E%0A%3CLI%3EIf%20you%20have%20hard%20coded%20properties%20like%20Issuer%2C%20Subject%20Name%2C%20Alternative%20DNS%2C%20or%20Thumbprint%20of%20any%20certificate%20other%20than%20the%20%3CSTRONG%3EBaltimore%20Root%20CA%3C%2FSTRONG%3E%2C%20then%20you%20will%20need%20to%20modify%20this%20to%20reflect%20the%20properties%20of%20the%20newly%20pinned%20certificates.%3C%2FLI%3E%0A%3CLI%3ENote%3A%20This%20extra%20validation%2C%20if%20done%2C%20should%20cover%20%3CSTRONG%3Eall%3C%2FSTRONG%3E%20the%20pinned%20certificates%20to%20prevent%20future%20disruptions%20in%20connectivity.%3C%2FLI%3E%0A%3C%2FOL%3E%0A%3C%2FLI%3E%0A%3C%2FOL%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CH2%20id%3D%22toc-hId--588402292%22%20id%3D%22toc-hId--588402318%22%3EValidation%3C%2FH2%3E%0A%3CP%3EWe%20recommend%20performing%20some%20basic%20validation%20to%20mitigate%20any%20unintentional%20impact%20to%20your%20IoT%20infrastructure%20connecting%20to%20Azure%20IoT%20Hub%20and%20DPS.%20We%20have%20set%20up%20a%20test%20environment%20for%20your%20convenience%20to%20try%20out%20before%20we%20roll%20these%20certificates%20in%20production%20environments.%20The%20connection%20strings%20for%20this%20test%20environment%20are%20given%20below%3A%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CUL%3E%0A%3CLI%3EIoT%20Hub%3A%20Use%20the%20provided%20connection%20string%20in%20your%20device%20or%20simulated%20runtime%20to%20test%20TLS%20connectivity%20to%20IoT%20Hub%20-%26nbsp%3B%3C%2FLI%3E%0A%3CUL%3E%0A%3CLI%3EConnection%20String%3A%20HostName%3Dsdk-cert-test.azure-devices.net%3BDeviceId%3DInvalidDevice1%3BSharedAccessKey%3D4aWn2y3hEEmLyWmvixeVl69SFzzSwXKwzkGDHsCaSZo%3D%3C%2FLI%3E%0A%3C%2FUL%3E%0A%3C%2FUL%3E%0A%3CUL%3E%0A%3CLI%3EDevice%20Provisioning%20Service%20(DPS)%3A%20Use%20your%20device%20ID%20and%20associated%20credential%20to%20authenticate%20with%20DPS%20using%20the%20following%20endpoint%20details%20-%3C%2FLI%3E%0A%3CUL%3E%0A%3CLI%3EGlobal%20Service%20Endpoint%3A%20global-canary.azure-devices-provisioning.net%3C%2FLI%3E%0A%3CLI%3EID%20SCOPE%3A%200ne0017FD54%3C%2FLI%3E%0A%3C%2FUL%3E%0A%3C%2FUL%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EA%20successful%20TLS%20connection%20to%20the%20test%20environment%20indicates%20a%20positive%20test%20outcome%20-%20that%20your%20infrastructure%20will%20work%20as%20is%20with%20these%20changes.%20The%20test%20connection%20string%20for%20IoT%20Hub%20contains%20an%20invalid%20key%2C%20so%20once%20the%20TLS%20connection%20has%20been%20established%2C%20any%20run%20time%20operations%20performed%20against%20this%20test%20IoT%20Hub%20will%20fail.%20For%20DPS%2C%20since%20your%20device%20has%20not%20been%20formally%20enrolled%20in%20this%20specific%20DPS%20instance%2C%20it%20is%20expected%20to%20get%20an%20authorization%20error.%20This%20is%20by%20design%20since%20these%20resources%20exist%20solely%20for%20customers%20to%20validate%20their%20TLS%20connectivity.%20The%20test%20environment%20will%20be%20available%20until%20all%20public%20cloud%20regions%20have%20been%20updated.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CH2%20id%3D%22toc-hId-1899110541%22%20id%3D%22toc-hId-1899110515%22%3ESupport%3C%2FH2%3E%0A%3CP%3EIf%20you%20have%20any%20technical%20questions%20on%20implementing%20these%20changes%20or%20help%20in%20performing%20validation%20in%20the%20test%20environment%2C%20please%20open%20a%20%3CA%20href%3D%22https%3A%2F%2Fms.portal.azure.com%2F%23blade%2FMicrosoft_Azure_Support%2FHelpAndSupportBlade%2Fnewsupportrequest%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Esupport%20request%3C%2FA%3E%20with%20the%20options%20below%20and%20a%20member%20from%20our%20engineering%20team%20will%20get%20back%20to%20you%20shortly.%3C%2FP%3E%0A%3CUL%3E%0A%3CLI%3EIssue%20Type%3A%20Technical%3C%2FLI%3E%0A%3CLI%3EService%3A%20IoT%20SDKs%3C%2FLI%3E%0A%3CLI%3ESummary%3A%20TLS%20Baltimore%20upgrade%20question%3C%2FLI%3E%0A%3CLI%3EProblem%20type%3A%20Connectivity%3C%2FLI%3E%0A%3CLI%3EProblem%20subtype%3A%20Unable%20to%20connect%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FLI%3E%0A%3C%2FUL%3E%0A%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-center%22%20image-alt%3D%22Untitled%20picture.png%22%20style%3D%22width%3A%20560px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F220294iF1C2AA8F9BAC5A61%2Fimage-dimensions%2F560x315%3Fv%3D1.0%22%20width%3D%22560%22%20height%3D%22315%22%20title%3D%22Untitled%20picture.png%22%20alt%3D%22Untitled%20picture.png%22%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%20class%3D%22lia-align-center%22%3E%3CEM%20style%3D%22font-family%3A%20inherit%3B%22%3EFig%201%3A%20Sample%20support%20request%3C%2FEM%3E%3C%2FP%3E%0A%3CP%3E%3CSTRONG%3E%26nbsp%3B%3C%2FSTRONG%3E%3C%2FP%3E%0A%3CH2%20id%3D%22toc-hId-91656078%22%20id%3D%22toc-hId-91656052%22%3EAdditional%20Information%3C%2FH2%3E%0A%3COL%3E%0A%3CLI%3EIoT%20Show%3A%20To%20know%20more%20about%20TLS%20certificates%20and%20PKI%20changes%20related%20to%20Azure%20IoT%2C%20please%20check%20out%20the%20IoT%20Show%3A%3CBR%20%2F%3E%3CBR%20%2F%3E%3CP%20align%3D%22Center%22%3E%3CIFRAME%20src%3D%22https%3A%2F%2Faka.ms%2Fiotshow%2F233%2Fyoutube%2Fembed%22%20width%3D%22560%22%20height%3D%22315%22%20frameborder%3D%220%22%20allowfullscreen%3D%22allowfullscreen%22%20allow%3D%22accelerometer%3B%20autoplay%3B%20encrypted-media%3B%20gyroscope%3B%20picture-in-picture%22%3E%3C%2FIFRAME%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FP%3E%0A%3C%2FLI%3E%0A%3CLI%3EMicrosoft%20wide%20communications%3A%20To%20broadly%20notify%20customers%2C%20Microsoft%20had%20sent%20a%20Service%20Health%20portal%20notification%20on%20Aug%203%3CSUP%3Erd%3C%2FSUP%3E%2C%202020%20and%20released%20a%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fkey-vault%2Fgeneral%2Fwhats-new%23azure-tls-certificate-changes%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3Epublic%20document%3C%2FA%3E%20that%20include%20timelines%2C%20actions%20that%20need%20to%20be%20taken%2C%20and%20details%20regarding%20the%20upcoming%20changes%20to%20our%20Public%20Key%20Infrastructure%20(PKI).%3C%2FLI%3E%0A%3C%2FOL%3E%3C%2FLINGO-BODY%3E%3CLINGO-TEASER%20id%3D%22lingo-teaser-1658456%22%20slang%3D%22en-US%22%3E%3CP%3E%3CSTRONG%3EHere%20is%20some%20important%20information%20about%20TLS%20certificate%20changes%20for%20Azure%20IoT%20Hub%20and%20DPS%20endpoints%20that%20may%20impact%20client%20connectivity.%3C%2FSTRONG%3E%3C%2FP%3E%0A%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20image-alt%3D%22RAMIoT_0-1599857580000.png%22%20style%3D%22width%3A%20999px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F217845i4C300A48E753E1FB%2Fimage-size%2Flarge%3Fv%3D1.0%26amp%3Bpx%3D999%22%20title%3D%22RAMIoT_0-1599857580000.png%22%20alt%3D%22RAMIoT_0-1599857580000.png%22%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-TEASER%3E
Microsoft

Microsoft is updating Azure services in a phased manner to use TLS server certificates from a different set of Certificate Authorities (CAs) beginning August 13, 2020 and concluding approximately on October 26, 2020. We expect that most Azure IoT customers that interact with IoT Hub and DPS will not be impacted; however, your application may be impacted if you explicitly specify a list of acceptable CAs (a practice known as “certificate pinning”). This change is limited to services in public Azure cloud and no sovereign cloud like Azure China.

 

This change is being made because the current CA certificates do not comply with one of the CA/Browser Forum Baseline requirements. This was reported on July 1, 2020 and impacts multiple popular Public Key Infrastructure (PKI) providers worldwide. Today, most of the TLS certificates used by Azure services are issued from the "Baltimore CyberTrust Root" PKI.

The following services used by Azure IoT devices will remain chained to the Baltimore CyberTrust Root*, but their TLS server certificates will be issued by new Intermediate Certificate Authorities (ICAs) starting October 5, 2020 progressing regionally through the month on a measured deployment schedule:

  1. Azure IoT Hub
  2. Azure IoT Hub Device Provisioning Service (DPS)
  3. Azure Storage Services

 

If any client application or device has pinned to an Intermediate CA or leaf certificate rather than the Baltimore CyberTrust Root, immediate action is required to prevent disruption of IoT device connectivity to Azure.

 

* Other Azure service TLS certificates may be issued by a different PKI.

 

Certificate Renewal Summary

The table below provides information about the certificates that are being rolled. Depending on which certificate your device or gateway clients use for establishing TLS connections, action may be needed to prevent loss of connectivity.

 

Certificate

Current

Post Rollover (Oct 5, 2020)

Action

Root

Thumbprint: d4de20d05e66fc53fe1a50882c78db2852cae474
Expiration: Monday, May 12, 2025, 4:59:00 PM
Subject Name:
CN = Baltimore CyberTrust Root

OU = CyberTrust
O = Baltimore
C = IE

 

 

 

Not Changing

None

Intermediates

Thumbprints:

 

CN = Microsoft IT TLS CA 1

Thumbprint: 417e225037fbfaa4f95761d5ae729e1aea7e3a42

----------------------------------------------------

CN = Microsoft IT TLS CA 2

Thumbprint: 54d9d20239080c32316ed9ff980a48988f4adf2d

----------------------------------------------------

CN = Microsoft IT TLS CA 4

Thumbprint: 8a38755d0996823fe8fa3116a277ce446eac4e99

----------------------------------------------------

CN = Microsoft IT TLS CA 5

Thumbprint: Ad898ac73df333eb60ac1f5fc6c4b2219ddb79b7

----------------------------------------------------

 

Expiration: ‎Friday, ‎May ‎20, ‎2024 5:52:38 AM
Subject Name:

OU = Microsoft IT

O = Microsoft Corporation

L = Redmond

S = Washington

C = US

Thumbprints:

 

CN = Microsoft RSA TLS CA 01

Thumbprint: 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a   

----------------------------------------------------

CN = Microsoft RSA TLS CA 02

Thumbprint: b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75

----------------------------------------------------

 

Expiration: ‎Tuesday, ‎October ‎8, ‎2024 12:00:00 AM;
Subject Name:

O = Microsoft Corporation

C = US

Required

Leaf (IoT Hub)
 

Thumbprint: 8b1a359705188c5577cb2dcd9a06331807c0bb97
Expiration: ‎Friday, ‎March ‎19, ‎2021 6:15:48 PM

Subject Name:

CN = *.azure-devices.net

Thumbprint: Varies
Expiration: Varies
Subject Name:
CN = *.azure-devices.net

Required

Leaf (DPS)
 

Thumbprint: f568f692f3274ecbb479c94272d6f3344a3f0247
Expiration: ‎Friday, ‎March ‎19, ‎2021 5:58:35 PM

Subject Name:

CN = *.azure-devices-provisioning.net

Thumbprint: Varies
Expiration: Varies
Subject Name:
CN = *.azure-devices-provisioning.net

Required

Note: Both the intermediate and leaf certificates are expected to change frequently. We recommend not taking dependencies on them and instead pinning the root certificate as it rolls less frequently.

 

 

Action Required

  1. If your devices depend on the operating system certificate store for getting these roots or use the device/gateway SDKs as provided, then no action is required.
  2. If your devices pin the Baltimore root CA among others, then no action is required related to this change.
    1. If your device interacts with other Azure services (e.g. IoT Edge -> Microsoft Container Registry or Device -> Azure API Gateway), then you must pin additional roots as provided here.
  3. If your devices use a connection stack other than the ones provided in an Azure IoT SDK, and pin any intermediary or leaf TLS certificates instead of the Baltimore root CA, then immediate action is required:
    1. To continue without disruption due to this change, Microsoft recommends that client applications or devices pin the Baltimore root -
      1. Baltimore Root CA
        (Thumbprint: d4de20d05e66fc53fe1a50882c78db2852cae474)
      2. To prevent future disruption, client applications or devices should also pin the following roots:
        1. Microsoft RSA Root Certificate Authority 2017
          (Thumbprint: 73a5e64a3bff8316ff0edccc618a906e4eae4d74)
        2. Digicert Global Root G2
          (Thumbprint: df3c24f9bfd666761b268073fe06d1cc8d4f82a4)
    2. To continue pinning intermediaries, replace the existing certificates with the new intermediates CAs:
      1. Microsoft RSA TLS CA 01
        (Thumbprint: 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a)
      2. Microsoft RSA TLS CA 02
        (Thumbprint: b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75)
      3. To minimize future code changes, also pin the following ICAs:
        1. Microsoft Azure TLS Issuing CA 01
          (Thumbprint: 2f2877c5d778c31e0f29c7e371df5471bd673173)
        2. Microsoft Azure TLS Issuing CA 02
          (Thumbprint: e7eea674ca718e3befd90858e09f8372ad0ae2aa)
        3. Microsoft Azure TLS Issuing CA 05
          (Thumbprint: 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5)
        4. Microsoft Azure TLS Issuing CA 06
          (Thumbprint: 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0)
  1. If your client applications, devices, or networking infrastructure (e.g. firewalls) perform any sub root validation in code, immediate action is required:
    1. If you have hard coded properties like Issuer, Subject Name, Alternative DNS, or Thumbprint of any certificate other than the Baltimore Root CA, then you will need to modify this to reflect the properties of the newly pinned certificates.
    2. Note: This extra validation, if done, should cover all the pinned certificates to prevent future disruptions in connectivity.

 

Validation

We recommend performing some basic validation to mitigate any unintentional impact to your IoT infrastructure connecting to Azure IoT Hub and DPS. We have set up a test environment for your convenience to try out before we roll these certificates in production environments. The connection strings for this test environment are given below: 

 

  • IoT Hub: Use the provided connection string in your device or simulated runtime to test TLS connectivity to IoT Hub - 
    • Connection String: HostName=sdk-cert-test.azure-devices.net;DeviceId=InvalidDevice1;SharedAccessKey=4aWn2y3hEEmLyWmvixeVl69SFzzSwXKwzkGDHsCaSZo=
  • Device Provisioning Service (DPS): Use your device ID and associated credential to authenticate with DPS using the following endpoint details -
    • Global Service Endpoint: global-canary.azure-devices-provisioning.net
    • ID SCOPE: 0ne0017FD54

 

A successful TLS connection to the test environment indicates a positive test outcome - that your infrastructure will work as is with these changes. The test connection string for IoT Hub contains an invalid key, so once the TLS connection has been established, any run time operations performed against this test IoT Hub will fail. For DPS, since your device has not been formally enrolled in this specific DPS instance, it is expected to get an authorization error. This is by design since these resources exist solely for customers to validate their TLS connectivity. The test environment will be available until all public cloud regions have been updated.

 

Support

If you have any technical questions on implementing these changes or help in performing validation in the test environment, please open a support request with the options below and a member from our engineering team will get back to you shortly.

  • Issue Type: Technical
  • Service: IoT SDKs
  • Summary: TLS Baltimore upgrade question
  • Problem type: Connectivity
  • Problem subtype: Unable to connect

Untitled picture.png

Fig 1: Sample support request

 

Additional Information

  1. IoT Show: To know more about TLS certificates and PKI changes related to Azure IoT, please check out the IoT Show:



  2. Microsoft wide communications: To broadly notify customers, Microsoft had sent a Service Health portal notification on Aug 3rd, 2020 and released a public document that include timelines, actions that need to be taken, and details regarding the upcoming changes to our Public Key Infrastructure (PKI).
7 Comments
Regular Visitor

@RAMIoT 

 

How will these change affect Microsoft Azure Sphere and Windows IOT Core devices?  Will those devices be automatically be updated with firmware/OS updates pushed out by Microsoft, assuming they have network connectivity back to the public internet?   

Microsoft

Azure Sphere utilizes the certificate provided in the Azure IoT C SDK that runs on Sphere. Since the SDK has the Baltimore root, this change should not impact default configurations of the Azure IoT C SDK on Sphere. However, if there have been intentional changes to include extra validation of ICAs or leaf certificates, some changes may be needed per the blog. 

For Windows IoT, the cert store has the existing Baltimore root already. This is not changing. Of course, if there is code that performs extra validation of ICAs or leaf certificates, or if these have been pinned, then some changes may be needed. 

Occasional Visitor

@RAMIoT 

What if we use only self-signed certificates with device SDK without pinned the Baltimore root CA explicitly, is it required any actions?

Microsoft

@marusyk 

 

I believe the flow you're talking about is for device authentication by the hub - devices can be provisioned with self signed certificates whose thumbprints are uploaded to hub so that hub can authenticate them. This flow is unchanged. 

What's changing is the way the device authenticates the service through TLS. The server (IoT Hub or DPS) will present a SSL certificate rooted to Baltimore with different intermediate CAs starting Oct 5th. If you are using the default C device SDK, the Baltimore root is pinned, and you should be okay. If you have performed any extra validation against any certificate that is not the Baltimore root, you may need to update that code. 

 

Hope this helps! 

Occasional Visitor

@RAMIoT 

We are using self signed certificate to provision devices into iot hub. Our Device is provisioning to IoT Hub via Azure DPS. We had Azure Device SDK on Device which connect to DPS using global endpoint "global.azure-devices-provisioning.net", ID Scope, and device certificates X.509 (Created using Self Signed Certificate). Once Device is provisioned on Azure IoT Hub using DPS, device will start communicating to IoT hub using device certificates X.509 and Device ID. We hadn't pinned certificates on device.

 

Does is there any impact based on above implementation approach?

 

We also tried to connect to DPS using test environment provided by Azure in this blog. We used our existing device valid certificates which are chaining to self signed root certificate and try to connect with below endpoints. But we are getting error code 401002. Below is the response which we got.

{"errorCode":401002,"trackingId":"****************************","message":"Invalid certificate.","timestampUtc":"2020-09-22T16:26:59.3100404Z"}
  • Azure Test Environment
    • Global Service Endpoint: global-canary.azure-devices-provisioning.net
    • ID SCOPE: 0ne0017FD54

 

What steps we need to follow to prevent disconnection of devices from azure?

 

Thanks,

Rajan

Microsoft

Hi @rajanpatel,

 

The flow you're referring to is how IoT Hub authenticates devices; there are 3 methods - Symmetric Key, X.509 self signed, and X.509 CA. These flows are not impacted. The TLS Server Certificates of Hub and DPS are changing and hence impacted. This means that when establishing a TLS connection with the IoT Hub or global DPS endpoint, the device must validate the server by looking up at the root chain and validating that the root certificate (in this case 'Baltimore Cyber Trust Root') is indeed a trusted CA on the device. 

The error you are receiving is because the test DPS instance does not have your device enrolled. If you'd like to test that, please open a support ticket as described in the Support section above, and our support team will be happy to enroll your device and allow you to perform an end to end test. If you're able to independently test that you're able to establish a TLS connection using wireshark then that's the only validation required. Hope this helps! :)

Frequent Visitor

I am using IoT DPS and IoT Hub from Linux VM + IoT Python SDK. My understanding is that I am not impacted based on input which you provided:

"If your devices depend on the operating system certificate store for getting these roots or use the device/gateway SDKs as provided, then no action is required."

In addition I did following test with curl:

 

[admin@node01 ~]$ curl -v https://global-canary.azure-devices-provisioning.net:8883
* About to connect() to global-canary.azure-devices-provisioning.net port 8883 (#0)
*   Trying 52.225.179.220...
* Connected to global-canary.azure-devices-provisioning.net (52.225.179.220) port 8883 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS: client certificate not found (nickname not specified)
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
*       subject: CN=*.azure-devices-provisioning.net
*       start date: Sep 08 21:29:05 2020 GMT
*       expire date: Sep 08 21:29:05 2021 GMT
*       common name: *.azure-devices-provisioning.net
*       issuer: CN=Microsoft RSA TLS CA 01,O=Microsoft Corporation,C=US
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: global-canary.azure-devices-provisioning.net:8883
> Accept: */*
>
* Empty reply from server
* Connection #0 to host global-canary.azure-devices-provisioning.net left intact
curl: (52) NSS: client certificate not found (nickname not specified)
[admin@node01 ~]$ curl -v https://sdk-cert-test.azure-devices.net:8883
* About to connect() to sdk-cert-test.azure-devices.net port 8883 (#0)
*   Trying 52.180.177.125...
* Connected to sdk-cert-test.azure-devices.net (52.180.177.125) port 8883 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS: client certificate not found (nickname not specified)
* SSL connection using TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
*       subject: CN=*.azure-devices.net
*       start date: Sep 10 21:15:38 2020 GMT
*       expire date: Sep 10 21:15:38 2021 GMT
*       common name: *.azure-devices.net
*       issuer: CN=Microsoft RSA TLS CA 01,O=Microsoft Corporation,C=US
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: sdk-cert-test.azure-devices.net:8883
> Accept: */*
>
* Empty reply from server
* Connection #0 to host sdk-cert-test.azure-devices.net left intact
curl: (52) NSS: client certificate not found (nickname not specified)
[admin@node01 ~]$

In case of issues with validation of the server certificate, curl reports it and "-k, --insecure" option is needed to skip validation of the server cert.

Does the above test confirm that I will not be impacted?

 

Thanks,

Leszek