กรณีปัญหาระหว่างกูเกิลกับไซแมนเทคเกี่ยวกับการออกใบรับรองดิจิตอลที่ไม่เป็นไปตามมาตรฐานมาเป็นเวลานาน (ทั้งที่ออกโดยไซแมนเทคเองและที่ออกโดย (อดีต) ตัวแทนของไซแมนเทค) ซึ่งทำให้กูเกิลได้เตรียมมาตรการเพื่อปกป้องผู้ใช้งานเว็บเบราว์เซอร์ Chrome เอาไว้แล้วนั้น ได้พบว่าการยกเลิกการโชว์สถานะ EV หรือที่เรียกกันว่าแถบ Green Bar ซึ่งเป็นหนึ่งในมาตรการที่กูเกิลได้เตรียมที่จะนำมาใช้นั้นเหมือนจะได้มีผลบังคับใช้ไปแล้วทั้งที่ยังไม่ถึงกำหนดเวลา โดยเฉพาะเว็บธนาคารในไทยซึ่งส่วนใหญ่จะใช้ใบรับรองแบบ EV ที่ออกโดยไซแมนเทคนั้น มีหลายเว็บที่พบว่าแถบ Green Bar ดังกล่าวได้หายไปแล้ว แต่ของบางเว็บก็ยังคงมีอยู่ ทำให้เกิดความสับสนว่านี่เป็นการเริ่มต้นแล้วของมาตรการการดังกล่าวของกูเกิลใช่หรือไม่ ซึ่งแท้จริงแล้วนั้นปัญหานี้ไม่เกี่ยวกันกับมาตรการข้างต้นที่กูเกิลได้เตรียมที่จะนำมาใช้แต่อย่างใด หากแต่เป็นปัญหาที่ได้เกิดขึ้นมาก่อนแต่เพิ่งจะได้มีการค้นพบในช่วงนี้พอดี ซึ่งสาเหตุของปัญหาดังกล่าวได้ถูกเปิดเผยโดยกูเกิลเองว่าเกิดจากการเรียง เลข OID ในส่วนของ Certificate Policies ผิดของใบรับรองที่ออกโดยไซแมนเทค

ตามปกติแล้วใบรับรองทุกใบจะมีการระบุข้อกำหนดที่ต้องปฎิบัติตามของ CA ไว้ในส่วนของ Certificate Policies ซึ่งเป็นการระบุโดยใช้เลข OID (ที่ไม่ซ้ำกัน) ซึ่งแม็พกับข้อกำหนด (Policy) ของใบรับรองแต่ละประเภท (ไม่ว่าจะเป็น DV, OV, EV, Code Signing, Code Signing แบบ EV) ของ CA แต่ละเจ้า ซึ่งการที่เบราว์เซอร์แต่ละตัวจะตัดสินใจว่าจะขึ้นสถานะ EV ให้หรือไม่สำหรับใบรับรองแต่ละใบนั้น ก็โดยการเช็คจากเลข OID นี้ว่าเป็นเลข OID ที่ได้ผ่านการรับรองแล้วว่าสามารถใช้เพื่อการออกใบรับรองแบบ EV ได้ หรือไม่ ซึ่งเลข OID ที่ใช้เพื่อการออกใบรับรองแบบ EV ที่ไซแมนเทคสามารถใช้ได้นั้นได้แก่

• 2.16.840.1.113733.1.7.23.6 (VeriSign) [Tree View]
• 2.16.840.1.113733.1.7.48.1 (Thawte) [Tree View]
• 1.3.6.1.4.1.14370.1.6 (GeoTrust) [Tree View]

นอกเหนือจากการระบุเลข OID ของตนเองลงไปใน Certificate Policies แล้ว CA หลายรายยังได้มีการใส่เลข OID 2.23.140.1.1 ของ CA/Browser Forum เข้าไปด้วย เพื่อบ่งบอกว่าได้มีการปฏิบัติตามข้อกำหนดนั้นเช่นกัน โดยตามปกติ CA จะเรียงให้เลข OID ของตนเองขึ้นก่อนแล้วตามด้วยเลข OID ของ CA/Browser Forum แต่ใบรับรอง EV ที่ออกโดยไซแมนเทคที่มีปัญหากับ Chrome 57 นั้น ได้เรียงเอาเลข OID 2.23.140.1.1 นี้ขึ้นก่อน แล้วให้เลข OID 2.16.840.1.113733.1.7.23.6 ตามหลัง จึงทำให้ Chrome เข้าใจผิดคิดว่าใบรับรองนี้ไม่ใช่ใบรับรอง EV เนื่องจาก Chrome จะเช็ค OID แรกเพียงตัวเดียว ในขณะที่เบราว์เซอร์ตัวอื่นเช่น Firefox อาจเช็คทุกตัวเพื่อหาดูว่าในลิสต์มี OID ที่เป็นของใบรับรองแบบ EV หรือเปล่า ถ้ามีถึงจะโชว์ว่าเป็น EV ไม่ว่า OID ที่เป็น EV นั้นจะอยู่ลำดับใด

ซึ่งประเด็นนี้อาจเกิดการถกเถียงกันว่าใครผิด บางส่วนอาจมองว่า Chrome ผิดที่ไม่เช็คทุกๆ OID ในลิสต์แบบที่ Firefox ทำ แต่บางส่วนก็อาจมองว่าไซแมนเทคผิดที่ไม่เรียง OID หลักของตนเองที่ใช้เพื่อการออกใบรับรองแบบ EV ขึ้นมาเป็น OID แรก (ในใบรับรองกลุ่มที่มีปัญหากับ Chrome) และไซแมนเทคผิดที่มีกระบวนการสร้างใบรับรองที่เหมือนมีสองมาตรฐาน คือมาตรฐานนึงเอา 2.16.840.1.113733.1.7.23.6 ของตนเองขึ้นก่อนแล้วเอา 2.23.140.1.1 ของ CA/Browser Forum ตามหลัง แต่อีกมาตรฐานนึงดันเอา 2.23.140.1.1 มาขึ้นก่อนแล้วเอา 2.16.840.1.113733.1.7.23.6 ตามหลัง ซึ่งแสดงให้เห็นถึงการไม่มี consistency ในการทำงานของไซแมนเทคเอง พอๆกับการออกใบรับรองในภาพรวมที่ไม่ได้มาตรฐานมาเป็นเวลานานแล้วนั่นเอง

สรุปว่าปัญหานี้เกิดเฉพาะกับ Chrome 57 (ไม่นับตัว Beta ซึ่งเป็น Chrome 58 และตัว Dev กับ Canary ซึ่งเป็น Chrome 59 ซึ่งทั้งหมดนี้ยังไม่ได้ทำการทดสอบ) และน่าจะเกิดเฉพาะบน Windows และ Linux แต่อาจไม่เกิดบน Mac (เนื่องจากมีผู้รายงานว่าไม่พบปัญหาและยังไม่พบรายงานที่ชัดเจนว่าเกิดปัญหานี้บน Mac) และเกิดเฉพาะกับใบรับรอง EV ที่มี OID 2.23.140.1.1 ของ CA/Browser Forum นำหน้าเป็นตัวแรกแทนที่จะเป็น OID ของ CA เอง เช่นถ้าเป็นของไซแมนเทคที่ใช้ CA ของ VeriSign ก็ต้องให้ 2.16.840.1.113733.1.7.23.6 นำหน้าเป็นตัวแรก โดยวิธีแก้ไขที่เร็วที่สุดน่าจะเป็นการขอออกใบรับรองใหม่ซึ่งน่าจะทำได้ทันทีจากทางฝั่งลูกค้าที่เจอปัญหานี้ผ่านทาง Web-based PKI Management Console หากออกใบใหม่แล้วยังเป็นเหมือนเดิมก็อาจต้องคุยกับทาง CA โดยอาจยกตัวอย่างใบรับรองที่ไม่มีปัญหาประกอบไป ซึ่งถ้าเป็นเว็บธนาคารในไทยที่ดังๆที่ไม่มีปัญหาก็เช่น KTB netbank, KK Biz e-Banking, ธนาคารแห่งประเทศไทย เป็นต้น ส่วนที่มีปัญหาก็เช่น K-Cyber, Bualuang iBanking, Citibank เป็นต้น

เนื่องจากการไม่โชว์สถานะ EV เป็นเรื่องที่มีผลกับความเชื่อมั่น อีกทั้งยังถือเป็นการลงทุนที่ไม่คุ้มค่า เนื่องจากราคาของใบรับรอง EV นั้นแพงกว่าแบบธรรมดาอยู่มาก จึงน่าจะถือได้ว่าเป็นเรื่องที่เร่งด่วนพอสมควรสำหรับเว็บที่มีปัญหา เพราะหากรอให้ Chrome แก้ปัญหานี้ก็คงใช้เวลาพอประมาณ หรือหากจะเปลี่ยน CA ไปเลย (เพราะยังไงๆสุดท้ายก็คงต้องเปลี่ยนอยู่แล้วตอนที่กูเกิลเริ่มใช้มาตรการต่างๆข้างต้นจริงๆ) ก็อาจต้องใช้เวลาอีกเหมือนกัน

หากต้องการเช็คแบบเร็วๆว่าเว็บใดมีปัญหาบ้าง ก็อาจใช้ OpenSSL เช็คผ่านทาง Command Line ได้ดังนี้

ตัวอย่างของเว็บที่ใช้ใบรับรอง EV แบบที่ไม่มีปัญหากับ Chrome 57

openssl s_client -connect www.ktbnetbank.com:443 </dev/null 2>/dev/null | openssl x509 -text | grep -E "Issuer:|Subject:|Poli"

        Issuer: C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 3 EV SSL CA - G3
        Subject: jurisdictionC = TH, businessCategory = Private Organization, serialNumber = DOC:19940324, C = TH, ST = Bangkok, L = Wattana, O = KRUNG THAI BANK PUBLIC COMPANY LIMITED, OU = KRUNG THAI BANK PUBLIC COMPANY LIMITED, CN = www.ktbnetbank.com
            X509v3 Certificate Policies:
                Policy: 2.16.840.1.113733.1.7.23.6
                Policy: 2.23.140.1.1

ตัวอย่างของเว็บที่ใช้ใบรับรอง EV แบบที่มีปัญหากับ Chrome 57

openssl s_client -connect online.kasikornbankgroup.com:443 </dev/null 2>/dev/null | openssl x509 -text | grep -E "Issuer:|Subject:|Poli"

        Issuer: C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 3 EV SSL CA - G3
        Subject: jurisdictionC = TH, businessCategory = Private Organization, serialNumber = 0107536000315, C = TH, postalCode = 10140, ST = Bangkok, L = Ratburana, street = 1 Soi Rat Burana 27/1 Rat Burana Rd., O = KASIKORNBANK Public Co Ltd, OU = Retail And Sme E-Business Department, CN = online.kasikornbankgroup.com
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.1
                Policy: 2.16.840.1.113733.1.7.23.6