Misissued/Suspicious Symantec Certificates

21329 views
Skip to first unread message

Andrew Ayer

unread,
Jan 19, 2017, 4:46:38 PM1/19/17
to mozilla-dev-s...@lists.mozilla.org
I. Misissued certificates for example.com

On 2016-07-14, Symantec misissued the following certificates for example.com:

https://crt.sh/?sha256=A8F14F52CC1282D7153A13316E7DA39E6AE37B1A10C16288B9024A9B9DC3C4C6
https://crt.sh/?sha256=8B5956C57FDCF720B6907A4B1BC8CA2E46CD90EAD5C061A426CF48A6117BFBFA
https://crt.sh/?sha256=94482136A1400BC3A1136FECA3E79D4D200E03DD20B245D19F0E78B5679EAF48
https://crt.sh/?sha256=C69AB04C1B20E6FC7861C67476CADDA1DAE7A8DCF6E23E15311C2D2794BFCD11

I confirmed with ICANN, the owner of example.com, that they did not
authorize these certificates. These certificates were already revoked
at the time I found them.


II. Suspicious certificates for domains containing the word "test"

On 2016-11-15 and 2016-10-26, Symantec issued certificates for various
domains containing the word "test" which I strongly suspect were
misissued:

https://crt.sh/?sha256=b81f339b971eb763cfc686adbac5c164b89ad03f8afb55da9604fd0d416bbd21
https://crt.sh/?sha256=f45d090e1bf24738a8e86734aa7acf7c9e65b619eb19660b1f73c9973f11b841
https://crt.sh/?sha256=bcbc26c9e06c4fe1c9e4d55fa27a501c504ea84e23e114b8ac004f7c0776cd0b
https://crt.sh/?sha256=f0935ce297419cc148bde49a7a123f2b2419cdd52df8e7f49e7bba07fe872559
https://crt.sh/?sha256=3601ab49034e69d6e2137a80e511a0640252f444b75d6baca7bf4672c35652a5

I have not attempted to contact the owners of these domains for
confirmation, as doing so is probably not feasible (many of the domains
are owned by squatters). However, the following facts lead to me to
believe that these certificates were misissued:

1. The subject DNs contain clearly bogus values, such as:

C=KR, ST=1, L=1, O=12, OU=1
C=KR, ST=1, L=1, O=1, OU=1
C=KR, ST=1, L=1, O=12, OU=1
C=KR, ST=Test1, L=Test, O=Test

Note that the misissued example.com certificates also contain C=KR in
their subjects.

2. The third certificate in the list above contains a SAN for
DNS:*.crosscert.com - note that three of the misissued example.com
certificates contain "Crosscert" in their Subject Organization.

3. None of these certificates have been observed in the wild by Censys.
The live certificate for www.test.com was issued by Network Solutions.

4. The first two certificates in the list above both contain DNS SANs
for *all* of the following domains:

test.com
test1.com
test2.com
test3.com
test4.com
test5.com
test6.com
test7.com
test8.com
test9.com
test11.com

With the exception of test4.com and test8.com, these domains are
registered to different entities and appear to be wholly unrelated with
one another in both ownership and operation. It is unlikely that the
owners of these domains would collaborate to authorize these
certificates.

These certificates were already revoked at the time I found them.


III. Certificates with O=Test

Finally, Symantec has issued a large number of certificates with the
following attributes in the Subject:

C=KR, ST=test, L=test, O=test, OU=test

e.g.:

https://crt.sh/?sha256=09AECE5B94BBB8A9EE2152FA6FB7261630124918DA015EB3571508EF6D31DD30
https://crt.sh/?sha256=CC0A2AE0EF5B1A6CF242D7B4C77AC9F05B49494B42C8486B47804874734CFC1C
https://crt.sh/?sha256=F177AC0064167354025CE12B3914A0E056628DD31152B5DF22E41913FC9D9B45
https://crt.sh/?sha256=DA7B1D433C071DA7A389EE2A4CAB854B89E441277B41E608F05FB7C7C6B2A761

For more, see:

https://crt.sh/?O=test

I doubt there is an organization named "test" located in "test, Korea."

Regards,
Andrew

Steve Medin

unread,
Jan 19, 2017, 6:46:42 PM1/19/17
to Andrew Ayer, mozilla-dev-s...@lists.mozilla.org
Andrew, thank you for your efforts to report this issue. We are
investigating and will report our resolution, cause analysis, and corrective
actions once complete.

Kind regards,
Steven Medin
PKI Policy Manager, Symantec Corporation

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symant...@lists.mozilla.org] On Behalf Of
> Andrew Ayer
> Sent: Thursday, January 19, 2017 4:46 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Misissued/Suspicious Symantec Certificates
>
> I. Misissued certificates for example.com
>
> On 2016-07-14, Symantec misissued the following certificates for
> example.com:
>
> https://clicktime.symantec.com/a/1/LyhH99FiQBwyOqKcts8QGJ75k6
> TPEC_N7jOPRSjGhkA=?d=6VMu_T-
> sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx-
> S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7
> mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw-
> s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA-
> 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG
> oYn8PQTT6koyyBuC-
> 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW-
> AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw-
> p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3
> NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F%
> 3Fsha256%3DA8F14F52CC1282D7153A13316E7DA39E6AE37B1A10C16288B902
> 4A9B9DC3C4C6
> https://clicktime.symantec.com/a/1/_X1-
> P9bvSq0r_QG43YQ6BwhHeeRl4IrY8ebwWh9HWiQ=?d=6VMu_T-
> sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx-
> S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7
> mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw-
> s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA-
> 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG
> oYn8PQTT6koyyBuC-
> 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW-
> AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw-
> p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3
> NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F%
> 3Fsha256%3D8B5956C57FDCF720B6907A4B1BC8CA2E46CD90EAD5C061A426C
> F48A6117BFBFA
> https://clicktime.symantec.com/a/1/1ux2sxPZpTNuRjN4JV5qOj0550
> RDi16i7NLrqi0eFaY=?d=6VMu_T-sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx-
> S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7
> mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw-
> s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA-
> 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG
> oYn8PQTT6koyyBuC-
> 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW-
> AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw-
> p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3
> NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F%
> 3Fsha256%3D94482136A1400BC3A1136FECA3E79D4D200E03DD20B245D19F0E
> 78B5679EAF48
> https://clicktime.symantec.com/a/1/YT02EQBzJ13G0VwF_VLruHbKA
> Ep4LXe40icNc0DLwUA=?d=6VMu_T-
> sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx-
> S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7
> mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw-
> s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA-
> 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG
> oYn8PQTT6koyyBuC-
> 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW-
> AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw-
> p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3
> NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F%
> 3Fsha256%3DC69AB04C1B20E6FC7861C67476CADDA1DAE7A8DCF6E23E15311
> C2D2794BFCD11
>
> I confirmed with ICANN, the owner of example.com, that they did not
> authorize these certificates. These certificates were already revoked at
the
> time I found them.
>
>
> II. Suspicious certificates for domains containing the word "test"
>
> On 2016-11-15 and 2016-10-26, Symantec issued certificates for various
> domains containing the word "test" which I strongly suspect were
> misissued:
>
> https://clicktime.symantec.com/a/1/_0lsjfT3DHqxu1QJl2eBU5zx948r
> qJmGy-bHkTlww3c=?d=6VMu_T-sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx-
> S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7
> mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw-
> s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA-
> 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG
> oYn8PQTT6koyyBuC-
> 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW-
> AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw-
> p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3
> NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F%
> 3Fsha256%3Db81f339b971eb763cfc686adbac5c164b89ad03f8afb55da9604fd0
> d416bbd21
> https://clicktime.symantec.com/a/1/uF90PPzN7N3_lTMmPb8YzXKK
> AfWPKKNmpvo_prjlE3Y=?d=6VMu_T-
> sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx-
> S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7
> mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw-
> s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA-
> 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG
> oYn8PQTT6koyyBuC-
> 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW-
> AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw-
> p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3
> NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F%
> 3Fsha256%3Df45d090e1bf24738a8e86734aa7acf7c9e65b619eb19660b1f73c99
> 73f11b841
> https://clicktime.symantec.com/a/1/ezbB2-8KqYUHyXjQx5B-
> Vwf6tJJiGin6RaC_rwMyM7Y=?d=6VMu_T-
> sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx-
> S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7
> mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw-
> s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA-
> 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG
> oYn8PQTT6koyyBuC-
> 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW-
> AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw-
> p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3
> NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F%
> 3Fsha256%3Dbcbc26c9e06c4fe1c9e4d55fa27a501c504ea84e23e114b8ac004f7
> c0776cd0b
> https://clicktime.symantec.com/a/1/DvhFK5KhEvCMzdYbMfWcMszP
> yUmwumBtBw7KULICQNk=?d=6VMu_T-
> sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx-
> S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7
> mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw-
> s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA-
> 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG
> oYn8PQTT6koyyBuC-
> 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW-
> AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw-
> p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3
> NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F%
> 3Fsha256%3Df0935ce297419cc148bde49a7a123f2b2419cdd52df8e7f49e7bba0
> 7fe872559
> https://clicktime.symantec.com/a/1/bVc-
> 6BOqerbwbrXUNbJu8pE6Vy80A5iky_MQqAMWgaA=?d=6VMu_T-
> sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx-
> S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7
> mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw-
> s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA-
> 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG
> oYn8PQTT6koyyBuC-
> 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW-
> AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw-
> p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3
> NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F%
> 3Fsha256%3D3601ab49034e69d6e2137a80e511a0640252f444b75d6baca7bf46
> https://clicktime.symantec.com/a/1/uZoiIkm1yJ-
> wqrsj50BAsLnMXK8PZ3NxcouYQEZu9FQ=?d=6VMu_T-
> sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx-
> S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7
> mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw-
> s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA-
> 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG
> oYn8PQTT6koyyBuC-
> 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW-
> AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw-
> p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3
> NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F%
> 3Fsha256%3D09AECE5B94BBB8A9EE2152FA6FB7261630124918DA015EB35715
> 08EF6D31DD30
> https://clicktime.symantec.com/a/1/s2LLW3OI_Iy8EHFssVpBCwNmh
> ZYy1Fj3Jzz9JIZSFpQ=?d=6VMu_T-
> sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx-
> S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7
> mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw-
> s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA-
> 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG
> oYn8PQTT6koyyBuC-
> 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW-
> AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw-
> p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3
> NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F%
> 3Fsha256%3DCC0A2AE0EF5B1A6CF242D7B4C77AC9F05B49494B42C8486B4780
> 4874734CFC1C
> https://clicktime.symantec.com/a/1/A3K4rj0hMWJHEL8Gwbg3A3_fK
> cWxBCrko0KsDdX3jPw=?d=6VMu_T-
> sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx-
> S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7
> mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw-
> s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA-
> 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG
> oYn8PQTT6koyyBuC-
> 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW-
> AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw-
> p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3
> NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F%
> 3Fsha256%3DF177AC0064167354025CE12B3914A0E056628DD31152B5DF22E41
> 913FC9D9B45
> https://clicktime.symantec.com/a/1/8BpzYG4IsDaFzKnBM5ZFLCABF6
> 94TPWDHnQRABD_Yps=?d=6VMu_T-
> sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx-
> S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7
> mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw-
> s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA-
> 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG
> oYn8PQTT6koyyBuC-
> 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW-
> AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw-
> p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3
> NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F%
> 3Fsha256%3DDA7B1D433C071DA7A389EE2A4CAB854B89E441277B41E608F05F
> B7C7C6B2A761
>
> For more, see:
>
> https://clicktime.symantec.com/a/1/_sbN9qKZDejSAj1U7evxJlBm83
> RyY17fLL1MikfsplM=?d=6VMu_T-
> sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx-
> S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7
> mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw-
> s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA-
> 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG
> oYn8PQTT6koyyBuC-
> 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW-
> AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw-
> p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3
> NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F%
> 3FO%3Dtest
>
> I doubt there is an organization named "test" located in "test, Korea."
>
> Regards,
> Andrew
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

Nick Lamb

unread,
Jan 21, 2017, 9:09:05 AM1/21/17
to mozilla-dev-s...@lists.mozilla.org
On Thursday, 19 January 2017 21:46:38 UTC, Andrew Ayer wrote:
> 2. The third certificate in the list above contains a SAN for
> DNS:*.crosscert.com - note that three of the misissued example.com
> certificates contain "Crosscert" in their Subject Organization.

Crosscert aka Korea Electronic Certification Authority, Inc. has applied to the Mozilla root programme and was identified as a "Super CA" which I understand to mean that they themselves just sign other CA certificates for third parties.

Of course these certificates were issued by Symantec as a member of Mozilla's root programme, all responsibility for ensuring their CA doesn't issue bogus certificates lies with Symantec, not with Crosscert.

Steve Medin

unread,
Jan 21, 2017, 9:35:56 AM1/21/17
to Andrew Ayer, mozilla-dev-s...@lists.mozilla.org
The listed Symantec certificates were issued by one of our WebTrust audited
partners. We have reduced this partner's privileges to restrict further
issuance while we review this matter. We revoked all reported certificates
which were still valid that had not previously been revoked within the 24
hour CA/B Forum guideline - these certificates each had "O=test". Our
investigation is continuing.
> 2. The third certificate in the list above contains a SAN for
> DNS:*.crosscert.com - note that three of the misissued example.com
> certificates contain "Crosscert" in their Subject Organization.
>

Ryan Sleevi

unread,
Jan 23, 2017, 8:59:04 PM1/23/17
to Steve Medin, mozilla-dev-s...@lists.mozilla.org, Andrew Ayer
Steve,

While I understand that your investigation is ongoing, this does seem
extremely similar, if not identical, to Symantec's previous misissuance.

In that previous incident, Symantec took a number of steps - beginning with
reportedly immediately terminating the employees responsible and then
continuing to a comprehensive system overhaul, as detailed at
https://www.symantec.com/page.jsp?id=test-certs-update#

What is particularly concerning here is that your current explanations
suggest that either they are incomplete, or that Symantec's previous
answers were either misleading or incorrect. This is extremely concerning,
and I'm hoping you can clarify with answers to the following questions,
independent of your ongoing investigation and as soon as possible:

1) In response to the previous incident, Symantec indicated they hold a "no
compromise" bar for such breaches in the post titled "A tough day as
leaders". [1]
a) Do you believe that the steps to "reduce privileges" represent a
consistent application of that standard?
b) If not, what additional steps are you taking, consistent with your "no
compromise" standard?

2) In response to the previous incident, Symantec indicated that the use of
any privileged test tool would require senior leader justification from
both QA and Production Operations teams and approvals from the heads of
Engineering and Policy Compliance. [2]
a) Did Symantec mean that this was limited to validations performed by
Symantec, and not that of Registration Authorities fulfilling the duties
pursuant to Section 1.3.2 of the Baseline Requirements?
b) At the time Symantec made this statement, did Symantec have any
Registration Authorities fulfilling the duties pursuant to Section 1.3.2 of
the Baseline Requirements?
c) If such a statement was meant to be limited to Symantec, and not that
of Registration Authorities, why did Symantec not feel it was appropriate
to highlight that it did not extend to activities performed by Registration
Authorities?
d) If such a statement was not meant to be limited to Symantec, was such
a justification provided, and approvals granted, for the tool that allowed
such Registration Authorities to issue these certificates?

3) In response to the previous incident, Symantec indicated a comprehensive
review of issuance privileges was conducted to ensure only authorized
personnel have the ability to issue certificates, and that a quarterly
access review would be conducted to ensure this. [2]
a) Did such comprehensive review include that of Registration Authorities?
b) If not, why did Symantec not disclose that Registration Authorities
were excluded?
c) Is Symantec currently performing access reviews of Registration
Authorities?
d) If so, when does Symantec expect this to be completed?

4) In response to the previous incident, Symantec indicated it updated its
internal policies and procedures for test certificates as used for
commercial certificates. Further, it indicated that QA engineers and
authentication personnel were trained on updated practices for test
certificates. [2]
a) Did Symantec include Registration Authorities in the scope of that
training?
b) If not, why did Symantec not disclose that Registration Authorities
were excluded?
c) If so, why did Symantec's corrective actions for the previous
misissuance fail to prevent this continued misissuance?

5) You have indicated that you have at least one WebTrust audited partner
capable of causing issuance using Symantec-operated CAs.
a) Please provide a link to the audit results for each of these WebTrust
audited partners.
b) Have you suspended the capabilities of these partners until Symantec
completes its investigation?
c) If not, why not, and when do you expect to do so?

6) Does Symantec allow is Registration Authorities to deviate from the
policies and standards set forth by its CP, CPS, and internal policies and
controls?
a) If not, why did Symantec fail to detect that its Registration
Authorities were deviating from its policies for this long?
b) If so, where does Symantec disclose this deviation within its CP
and/or CPS?

7) When do you expect to provide the next update as to the ongoing
investigation? If it is not within the next three days, why?


Thank you for your time in answering each and every one of these questions
and providing further details, so as to help inform the broader community
as to the steps Symantec has taken and is taking to prevent continued
misissuance contrary to the Baseline Requirements and the Mozilla CA
Certificate Policy.

[1] http://archive.is/Ro70U
[2] https://www.symantec.com/page.jsp?id=test-certs-update

Hanno Böck

unread,
Jan 24, 2017, 4:38:42 AM1/24/17
to dev-secur...@lists.mozilla.org
Hello,

I have a few observations to share about this incident, not sure how
relevant they are.

There are 4 "example.com" certificates related to this incident.

There are 114 "O=test" certificates that I assume are related to this
incident. This includes all certificates with a "Not Before" date of
2016-10 and later. crt.sh finds various older certificates with O=test
from various CAs, but I guess they are unrelated.

Issuers
=======

The affected certificates were issued by three different intermediates
owned by Symantec:
Symantec Class 3 Secure Server CA - G4
thawte SSL CA -
GeoTrust SSL CA - G3

Now Symantec told us these certificates were issued by one of their
WebTrust partners. This got me curious if it's usual that Symantec
gives their partners access to their systems in a way that they can use
various different intermediates related to different brand names.

This document here
https://cert.webtrust.org/SealFile?seal=2168&file=pdf
indicates that Korea Electronic Certification Authority Inc.
("CrossCert"), which is probably the partner Symantec is talking about,
is allowed to issue certificates with these intermediates
VeriSign Class 3 Secure Server CA - G3
VeriSign Class 3 International Server CA - G3
Symantec Class 3 Secure Server CA - G4
Which - as can be obviously seen - don't match.

(nitpick: It seems the PDF doc has a bogus document title which looks
like some changelog entry)


Revocations
===========

The 4 example certs were already revoked when Andrew Ayer made this
incident public.
From the 114 "O=test" certificates 62 were revoked at some point in
2016, so before the incident became public. 52 were revoked at some
point in 2017. 37 of those were revoked on 2017-01-20, so directly
afterthe incident got public.
(I've counted this because in a statement sent to the media Symantec
said that when they learned about this incident "most" certificates
were already revoked. I feel I have a different definition of the word
"most".)


Other O=test certificates
=========================

A quick run through other "O=test" certs:
* "Cybertrust Japan Co.. Ltd." seems to have issued a large number of
them, but a few checks indicate they are issued to domains they own.
Not sure if that's still considered a problem, as "O=test" is
obviously a bogus org, but at least they seem to not issue certs for
other people's domains.
* There's one cert issued by "SHECA" which is itself an intermediate
signed by "UniTrust". It's issued for a public IP. UniTrust seems to
be accepted by Apple+Microsoft, but not by Mozilla+Chrome.
https://crt.sh/?id=32335050




--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

Andrew Ayer

unread,
Jan 24, 2017, 3:03:50 PM1/24/17
to Hanno Böck, dev-secur...@lists.mozilla.org
Hi Hanno,

On Tue, 24 Jan 2017 10:38:01 +0100
Hanno B__ck <ha...@hboeck.de> wrote:

> Hello,
>
> I have a few observations to share about this incident, not sure how
> relevant they are.

Thanks for sharing these. I found them interesting.

> There are 4 "example.com" certificates related to this incident.
>
> There are 114 "O=test" certificates that I assume are related to this
> incident. This includes all certificates with a "Not Before" date of
> 2016-10 and later. crt.sh finds various older certificates with O=test
> from various CAs, but I guess they are unrelated.

I count 101 distinct O=test certificates with a notBefore date of
2016-10 or later (of these, 2 also have DNS name for *test*.com; also,
there are 3 certs for *test*.com without O=Test). Might you be
double-counting certs and their corresponding pre-certs?

Regards,
Andrew

Ryan Sleevi

unread,
Jan 26, 2017, 12:52:32 PM1/26/17
to Ryan Sleevi, mozilla-dev-s...@lists.mozilla.org, Steve Medin, Andrew Ayer
Steve,

Have you had a chance to review these questions? Considering that these are
all about existing practices, and as a CA should be readily available and
easy to answer, I'm hoping you can reply by end of day.

Please consider this a formal request from Google as part of investigating
this incident.

Steve Medin

unread,
Jan 27, 2017, 12:27:52 AM1/27/17
to Andrew Ayer, mozilla-dev-s...@lists.mozilla.org
Here is an attached PDF update regarding this certificate problem report.

Kind regards,
Steven Medin
PKI Policy Manager, Symantec Corporation

Kathleen Wilson

unread,
Jan 27, 2017, 12:36:35 AM1/27/17
to mozilla-dev-s...@lists.mozilla.org
On Thursday, January 26, 2017 at 9:27:52 PM UTC-8, Steve Medin wrote:
> Here is an attached PDF update regarding this certificate problem report.
>
> Kind regards,
> Steven Medin
> PKI Policy Manager, Symantec Corporation
>


The PDF file provided by Steven has been attached to this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1334377

Direct link to pdf file:
https://bug1334377.bmoattachments.org/attachment.cgi?id=8831038

Cheers,
Kathleen

Ryan Sleevi

unread,
Jan 27, 2017, 12:36:57 AM1/27/17
to Steve Medin, mozilla-dev-s...@lists.mozilla.org, Andrew Ayer
The PDF that was stripped is available at
https://bug1334377.bmoattachments.org/attachment.cgi?id=8831038

On Thu, Jan 26, 2017 at 5:30 PM, Steve Medin <Steve...@symantec.com>
wrote:

> Here is an attached PDF update regarding this certificate problem report.
>
> Kind regards,
> Steven Medin
> PKI Policy Manager, Symantec Corporation
>
> > -----Original Message-----
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symant...@lists.mozilla.org] On Behalf Of Steve
> > Medin
> > Sent: Saturday, January 21, 2017 9:35 AM
> > To: Andrew Ayer <ag...@andrewayer.name>; mozilla-dev-security-
> > pol...@lists.mozilla.org
> > Subject: RE: Misissued/Suspicious Symantec Certificates
> >
> > The listed Symantec certificates were issued by one of our WebTrust
> audited
> > partners. We have reduced this partner's privileges to restrict further
> > issuance while we review this matter. We revoked all reported
> certificates
> > which were still valid that had not previously been revoked within the 24
> > hour CA/B Forum guideline - these certificates each had "O=test". Our
> > investigation is continuing.
> >
>

Jakob Bohm

unread,
Jan 27, 2017, 2:18:33 AM1/27/17
to mozilla-dev-s...@lists.mozilla.org
(continuing top post for consistency)

For the certificates that are noted as "revoked on the day of
issuance", it would (both in this and the general case), be more
informative to state the revocation delay in a smaller unit of measure,
such as hours (or even smaller if less than an hour).

It is of cause noted, that most of the relevant timestamps are (or were
at the time) recorded with a precision of 1s in published PKI objects,
although parties outside the CA not have an easy way to obtain reliable
copies of the revocation responses that the CA would have issued, and
thus the timestamps of revocation becoming known to revocation-checking
relying parties (which is different from the time that the revocation
may have been also communicated to independent logging systems).
Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Jakob Bohm

unread,
Jan 27, 2017, 2:36:27 AM1/27/17
to mozilla-dev-s...@lists.mozilla.org
(continuing top posting for consistency)

In order to clarify the potential risk/damage to the Web PKI, it would
be useful to clarify the following in a later report (since this would
require additional investigation):

Were the web identities (DNS names etc.) in the category C, D, E and F
certificates properly vetted as per the CP/CPS etc., the certificates
simply replaced the vetted organization name with "test" in the X.500
distinguished name? Or were some of those issued for insufficiently
(or actually incorrect) web identities?

To the safety of the web PKI this makes a big difference, since if the
web identities were properly and correctly vetted, then the only real
danger was relying parties seeing the word "test" in some user
interfaces instead of the real organization name, thus conferring less
trust (failing closed). If on the other hand the web identities were
insufficiently vetted, then the certificates conferred a security claim
to relying parties not being shown or otherwise inspecting the O= field
(failing open).

Gervase Markham

unread,
Jan 27, 2017, 7:11:06 AM1/27/17
to mozilla-dev-s...@lists.mozilla.org
Hi Steve,

On 27/01/17 01:30, Steve Medin wrote:
> Here is an attached PDF update regarding this certificate problem report.

Thanks for the update. Here are some questions:

* It's not clear what the problem is with the issuance in category F. I
don't see any mention of "dev119money.com" in Andrew's initial report.
Can you explain (and provide a crt.sh link)?

* Root Cause, bullet 2 refers to "certificates issued between July 2016
and January 2017"; is it correct that this corresponds to categories A
(one of four certificates), B, D, E and F?

* What processes, other than requiring and inspecting a WebTrust report,
does Symantec have in place to ensure that its RAs behave in accordance
with the CP and CPS of the Symantec-owned roots under which they are
issuing? (Perhaps this will be covered in the report you will issue
after the "additional follow-up" steps are completed?)

* Do such processes include regular, occasional or any review of the
audit logs which show the overriding of compliance failure flags?

Gerv

Nick Lamb

unread,
Jan 27, 2017, 12:43:10 PM1/27/17
to mozilla-dev-s...@lists.mozilla.org
On Friday, 27 January 2017 12:11:06 UTC, Gervase Markham wrote:
> * It's not clear what the problem is with the issuance in category F. I
> don't see any mention of "dev119money.com" in Andrew's initial report.
> Can you explain (and provide a crt.sh link)?

https://crt.sh/?id=48539119 appears to be the certificate in question.

The certificate is clearly bogus in that it identifies the Subject O=test, OU=test, etc. yet real DNS names are included in the SANs. It is not clear to me either why this is different from Category D and so I too would appreciate more information from Steven about that.

Steve Medin

unread,
Jan 28, 2017, 9:28:53 PM1/28/17
to mozilla-dev-s...@lists.mozilla.org
Symantec's auditors, KPMG, completed a scan of CrossCert certificates to
detect potential mis-issuance. On Thursday, January 26, 2017 at 4:08pm PST,
KPMG provided a report that listed 12 problem certificates that were not in
Andrew Ayer's report. We began an investigation into that certificate
problem report at 6:30pm PST Thursday. Six of the certificates contained
numbers in the locality, two were street addresses and four were Bangladeshi
postal codes appended to the city name. Six contained the word "test" in the
organization, but were false positives for legitimate organization names.

We completed our investigation of these 12 certificates by requesting
archived documentation. CrossCert was unable to produce documentation to
prove their validation as required under BR 5.4.1. We revoked all 12
certificates within 24 hours of becoming aware of CrossCert's BR 5.4.1
non-compliance. Our investigation continues.

Links:
https://crt.sh/?id=16869385
https://crt.sh/?id=11199825
https://crt.sh/?id=11633501
https://crt.sh/?id=11281299
https://crt.sh/?id=11283579
https://crt.sh/?id=12504637
https://crt.sh/?id=42016028
https://crt.sh/?id=13161832
https://crt.sh/?id=13161834
https://crt.sh/?id=13161835
https://crt.sh/?id=25211067
https://crt.sh/?id=47456180

Nick Lamb

unread,
Jan 29, 2017, 7:39:10 AM1/29/17
to mozilla-dev-s...@lists.mozilla.org
On Sunday, 29 January 2017 02:28:53 UTC, Steve Medin wrote:
> We completed our investigation of these 12 certificates by requesting
> archived documentation. CrossCert was unable to produce documentation to
> prove their validation as required under BR 5.4.1. We revoked all 12
> certificates within 24 hours of becoming aware of CrossCert's BR 5.4.1
> non-compliance. Our investigation continues.

Several of these certificates appear, on any surface inspection, to be legitimate certificates issued to real subscribers and yet presumably CrossCert was not able to document validation. So several thoughts arise, I appreciate that you might want to do more investigation before replying Steve, not least because there are quite a few questions here - and as always I welcome feedback from other participants meanwhile.

1. The six "false positive" certificates appear unremarkable except for the coincidence of including the word "test". If CrossCert can't produce documentation to show these were validated properly, it seems likely that many or even all certificates which Symantec had believed were validated by CrossCert in fact lack such documentation. Is that not so?

2. It had been my assumption, based on the CPS and other documents, that CrossCert was restricted in their use of Symantec's issuance function to C=KR, this is cold comfort for practical purposes in the Web PKI, but it would at least help us to scope any damage. The existence of certificates with C=BD in this list shows my assumption was wrong. How (if at all) can an outsider determine if in fact CrossCert caused issuance of a Symantec certificate ? Prior to Andrew's report what _mechanical_ constraints on CrossCert's issuance were in place, in particular any beyond those which were applied to Symantec's own issuances? For example, would it have been possible for them to cause issuance of a 5-year cert? A SHA-1 certificate? To choose specific serial numbers?

3. Since we have every reason to imagine that some (or even all) of the affected certificates were issued in good faith to legitimate subscribers, it would have been nice for Symantec to alert the subscribers when their certificates were revoked. Did Symantec do this? If not does Symantec have the capability to contact these subscribers itself (e.g. email addresses, phone numbers)? If not, does Symantec contractually require of RA partners that they provide a capability for Symantec to contact their subscribers, or relay a message chosen by Symantec on their behalf ?

4. Although BR 5.4.1 says that these records are to be kept by the CA and each Delegated Third Party the obligation is on the CA (here, Symantec) to make the records available to their auditors. Is it in fact the case that this investigation is the first time Symantec has asked Crosscert for such records ? Wasn't Symantec concerned that KPMG (in a routine audit) might ask to see these records but they didn't have them ? Might not other RA partners be affected similarly ?

5. As Symantec will know from its own experience, audits have not proved to be sufficient for detecting systematic non-compliance by CAs. What measures _beyond_ the Webtrust audit did Symantec have in place to detect non-compliance by an RA partner ?

Gervase Markham

unread,
Jan 30, 2017, 6:10:00 AM1/30/17
to mozilla-dev-s...@lists.mozilla.org
Hi Nick,

On 29/01/17 12:39, Nick Lamb wrote:
> 2. It had been my assumption, based on the CPS and other documents,
> that CrossCert was restricted in their use of Symantec's issuance
> function to C=KR

Could you point is at the parts of the CPS or other documents which led
you to that belief?

Gerv

Nick Lamb

unread,
Jan 30, 2017, 7:51:52 AM1/30/17
to mozilla-dev-s...@lists.mozilla.org
On Monday, 30 January 2017 11:10:00 UTC, Gervase Markham wrote:
> Could you point is at the parts of the CPS or other documents which led
> you to that belief?

I examined a great many documents since Andrew's initial report. I think the document which originally caused me to form this incorrect assumption was

CrossCert Certification Practice Statement
Version 3.8.8
Effective Date: JUNE 29, 2012

this file was available from
http://www.crosscert.com/symantec/certificationeng.pdf
and is linked from the 2016 WebTrust audit report for CrossCert

This document (which I will call CPS 3.8.8) contains a section 3.1.1 Type of Names which asserts

"End-user Subscriber Certificates contain an X.501 distinguished name in the Subject name field and consist of the components specified in Table 5 below."

Table 5 in CPS 3.8.8 says that the attribute Country (C) shall have the value “KR” or not used.

It seemed to me that this document established that as a Relying Party I should conclude an end entity certificate with C=BD is not from CrossCert. Perhaps there's _another_ CPS somewhere else that says otherwise ?

Gervase Markham

unread,
Jan 30, 2017, 9:35:43 AM1/30/17
to Nick Lamb
On 30/01/17 12:51, Nick Lamb wrote:
> CrossCert Certification Practice Statement Version 3.8.8 Effective
> Date: JUNE 29, 2012

That date is interesting. The BRs require CPSes to be revised yearly.

> "End-user Subscriber Certificates contain an X.501 distinguished name
> in the Subject name field and consist of the components specified in
> Table 5 below."
>
> Table 5 in CPS 3.8.8 says that the attribute Country (C) shall have
> the value “KR” or not used.

That seems reasonably conclusive on the face of it. I'm sure Steve will
have noted this point and I hope he will address it in any further
update on the CrossCert situation.

Gerv

Ryan Sleevi

unread,
Jan 30, 2017, 12:36:54 PM1/30/17
to Ryan Sleevi, mozilla-dev-s...@lists.mozilla.org, Steve Medin, Andrew Ayer
Steve,

As captured in our private mail exchange last week, Symantec's report fails
to meaningfully address each or any of the questions I raised. Google
considers it of utmost urgency that Symantec share the answers to these
questions, posed a week ago, and based on Symantec's multiple public
statements regarding the previous misissuance. Please confirm your receipt
of these questions and your intent to provide an answer to the community by
end of day, so that we can consider Symantec's answers when considering
appropriate next steps to protect our users. In the absence of timely
information from a CA following a misissuance, it's both necessary and
reasonable to consider the worst as plausible.

For your reference,
https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/chC7tXDgCQAJ

Andrew Ayer

unread,
Jan 30, 2017, 12:52:34 PM1/30/17
to Nick Lamb, mozilla-dev-s...@lists.mozilla.org
On Fri, 27 Jan 2017 09:43:00 -0800 (PST)
Nick Lamb <tiala...@gmail.com> wrote:

> On Friday, 27 January 2017 12:11:06 UTC, Gervase Markham wrote:
> > * It's not clear what the problem is with the issuance in category
> > F. I don't see any mention of "dev119money.com" in Andrew's initial
> > report. Can you explain (and provide a crt.sh link)?
>
> https://crt.sh/?id=48539119 appears to be the certificate in question.
>
> The certificate is clearly bogus in that it identifies the Subject
> O=test, OU=test, etc. yet real DNS names are included in the SANs. It
> is not clear to me either why this is different from Category D and
> so I too would appreciate more information from Steven about that.

I would appreciate confirmation from Steve, but note that dev119money.com
is not currently a registered domain name.

Regards,
Andrew

Nick Lamb

unread,
Jan 30, 2017, 5:52:13 PM1/30/17
to mozilla-dev-s...@lists.mozilla.org
On Monday, 30 January 2017 17:52:34 UTC, Andrew Ayer wrote:
> I would appreciate confirmation from Steve, but note that dev119money.com
> is not currently a registered domain name.

Ah yes, none of the names on that certificate currently exist in the Internet DNS: devhkhouse.co.kr and devhkautoloan.co.kr don't match anything either. Thank you for spotting this Andrew.

However the names hkhouse.co.kr and hkautoloan.co.kr do exist, they are both currently registered to HK savings bank in the wealthy (and now internationally famous) Gangnam district of Seoul. 911money.com also exists, but appears to be owned by a sketchy US outfit, possibly just harvesting vaguely finance-related domains for re-sale. However, m911money.com is owned by HK savings bank too. HK Savings Bank has certificates from Symantec today, I do not know if CrossCert acted as RA for these certificates.

So, I suppose that this certificate is essentially a typographical error on an enormous scale, like the (fictitious but popular) story that the UK's Guardian newspaper once managed to spell its own name in the masthead "Grauniad".

On this basis I think it's reasonably likely that CrossCert is merely spectacularly incompetent, it (at least sometimes and perhaps always) did not validate DNS names before causing Symantec to issue a certificate and so as a result instead of typo-ridden applications being rejected because they wouldn't validate, bogus certificates were issued.

Detecting such incompetence was Symantec's responsibility and we await any real information about why they failed to do that.

Steve Medin

unread,
Jan 30, 2017, 10:52:02 PM1/30/17
to mozilla-dev-s...@lists.mozilla.org
Our response to questions up to January 27, 2017 has been posted as an
attachment to bug https://bugzilla.mozilla.org/show_bug.cgi?id=1334377.



The direct attachment link is:
https://bugzilla.mozilla.org/attachment.cgi?id=8831933.



The bug report contains additional documentation supporting our response.



Kind regards,

Steven Medin
PKI Policy Manager, Symantec Corporation





Jakob Bohm

unread,
Jan 31, 2017, 1:41:42 PM1/31/17
to mozilla-dev-s...@lists.mozilla.org
Glad you also answered the key question I posted some time ago (the
last one in the PDF).

According to your answer it appears that the majority of problematic
certificates were, to the WebPKI relying parties, correct and valid
certificates that simply had the legal names of the certificate holders
safely replaced by the non-confusing (in several languages) word "test".

Such certificates, while they may technically violate one or more
CP/CPS/BR rules, are not really dangerous, as they provide the
information of a DV certificate with the stronger vetting of an OV
certificate.

However the incident seems to have revealed deeper and more serious
issues such as bad vetting and failure to retain vetting records.

On 31/01/2017 04:51, Steve Medin wrote:
> Our response to questions up to January 27, 2017 has been posted as an
> attachment to bug https://bugzilla.mozilla.org/show_bug.cgi?id=1334377.
>
>
>
> The direct attachment link is:
> https://bugzilla.mozilla.org/attachment.cgi?id=8831933.
>
>
>
> The bug report contains additional documentation supporting our response.
>
>
>
> Kind regards,
>
> Steven Medin
> PKI Policy Manager, Symantec Corporation
>


Gervase Markham

unread,
Feb 4, 2017, 6:11:42 AM2/4/17
to mozilla-dev-s...@lists.mozilla.org
On 31/01/17 04:51, Steve Medin wrote:
> Our response to questions up to January 27, 2017 has been posted as an
> attachment to bug https://bugzilla.mozilla.org/show_bug.cgi?id=1334377.

Quoting that document:

"Q: 4) In response to the previous incident, Symantec indicated it
updated its internal policies and procedures for test certificates as
used for commercial certificates. Further, it indicated that QA
engineers and authentication personnel were trained on updated practices
for test certificates. a) Did Symantec include Registration Authorities
in the scope of that training?

A: We did not train partners on an issue that pertained to a tool they
could not access."

-- That seems to miss the point of the question somewhat. The problem in
the previous incident was poor practices surrounding the issuance of
test certificates, not simply the tool that was used to issue them.

1) Did Symantec do any additional training for RAs regarding the
issuance of test certificates after the last incident? If not, why not?
Did Symantec believe that it was very unlikely for RA personnel to make
the same mistakes or have the same misunderstandings of what was
appropriate as Symantec's personnel?

You also write: "Category C concluded prior to that last audit’s review
period."

2) Is your understanding that, when WebTrust audits are sampling, they
sample only certificates issued during the review period? Or should they
be sampling certificates issued during the entire period covered by the
audit? If the latter, did their sampling (3%, isn't it?) hit any
Category C certificates? How many certificates were in the sample pool?

3) To be totally clear: would it be correct to say that up until this
point, examining WebTrust audits was the only mechanism that Symantec
used to _check_ the conformance of their RAs to Symantec's CP/CPS and
other requirements? (I see you give them software, and docs, and
training, but was this the only _checking_ mechanism?)

New question:

4) Is there any reliable programmatic way of determining, looking only
at the contents of the certificate or certificate chain, that a
certificate was issued by CrossCert personnel using their processes, as
opposed to by Symantec personnel or by another RA?

We look forward to hearing the answers to these questions and further
updates on the situation with CrossCert.

Thanks,

Gerv

Ryan Sleevi

unread,
Feb 4, 2017, 8:33:37 AM2/4/17
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
On Sat, Feb 4, 2017 at 3:10 AM, Gervase Markham <ge...@mozilla.org> wrote:
>
> 4) Is there any reliable programmatic way of determining, looking only
> at the contents of the certificate or certificate chain, that a
> certificate was issued by CrossCert personnel using their processes, as
> opposed to by Symantec personnel or by another RA?
>
> We look forward to hearing the answers to these questions and further
> updates on the situation with CrossCert.


Gerv, as the information Steve shared about their other RAs show, their
issues with RAs are not limited to CrossCert, unfortunately. Check out the
rest of the details included.

Steve: Given the many issues very clear from CrossCert's CP/CPS, and the
many audit issues disclosed in CertSuperior's report, I'd like to request
that you also disclose the CP/CPS for these CAs. For example, CertiSign's
CP/CPS is not immediately obvious to me as to what Symantec was relying on
EY to audit.

Gervase Markham

unread,
Feb 4, 2017, 9:38:28 AM2/4/17
to mozilla-dev-s...@lists.mozilla.org
On 04/02/17 14:32, Ryan Sleevi wrote:
> Gerv, as the information Steve shared about their other RAs show, their
> issues with RAs are not limited to CrossCert, unfortunately. Check out the
> rest of the details included.

Ouch. Thank you for drawing these to my attention; I had neglected to
read them.

Gerv

Martin Heaps

unread,
Feb 4, 2017, 7:43:12 PM2/4/17
to mozilla-dev-s...@lists.mozilla.org
As a side note to the main topic, I find it curious and a little disconcerting that the referred link to the E&Y assessement of CrossCert, (outlined in Point 2 of "Additional Follow-ups") found on the document linked by Steve (here :
https://bug1334377.bmoattachments.org/attachment.cgi?id=8831038 )

uses this web address for accessing the E&Y assessment: https://cert.webtrust.org/SealFile?seal=2168&file=pdf and that access this address gives a

> Secured Connection Failure: SSL_ERROR_UNSAFE_NEGOTIATION

status. This (webtrust) organisation which seems to run the role of certifying PKI distributing authorities (such as CrossCert, Symantec, etc) can't use a half decent security certificate for their own sites!

Disappointing.

p.s> Aferwards, running the address through SSLLabs Test it get's an F. See: https://www.ssllabs.com/ssltest/analyze.html?d=cert.webtrust.org

Very Disappointing.

Further information (you probably already know but just for competeness sake.

>From their website:
-----------------------------
What is the purpose of the WebTrust for CAs program

The WebTrust for CAs program helps to ensure that proper procedures are followed in activities involving e-commerce transactions, public key infrastructure (PKI), and cryptography. In online trust and e-commerce transactions, confidentiality, authentication, integrity, and nonrepudiation are vitally important. These requirements are satisfied using PKI and SSL Certificates. A certification authority verifies the identity of an organization/entity and issues a certificate that the organization can use to prove their identity.

CAs are taking an increasingly important role in the security of e-commerce. Although there are many national, international, and proprietary standards and guidelines for the use of cryptography, the management of digital certificates, and the policies and practices of CAs, these standards have not been applied uniformly. The AICPA/CICA WebTrust Program for Certification Authorities ensures that specific policies are implemented and enforced.
-----------------------------

And this organisation can't supply valid TLS certificates for their own websites? Jeeeeeeee

Peter Gutmann

unread,
Feb 5, 2017, 12:20:58 AM2/5/17
to Martin Heaps, mozilla-dev-s...@lists.mozilla.org
Martin Heaps <mar...@mhcreations.co.uk> writes:

>web address for accessing the E&Y assessment:
>https://cert.webtrust.org/SealFile?seal=2168&file=pdf and that access this
>address gives a
>
>> Secured Connection Failure: SSL_ERROR_UNSAFE_NEGOTIATION
>
>status. This (webtrust) organisation which seems to run the role of
>certifying PKI distributing authorities (such as CrossCert, Symantec, etc)
>can't use a half decent security certificate for their own sites!

That's not a cert issue, it's Firefox objecting to the version of SSL/TLS the
server is advertising. Hey, it would be pretty funny if the cert auditors'
certs were broken, but it's just the browser complaining about something else.

Peter.

Gervase Markham

unread,
Feb 5, 2017, 4:48:00 AM2/5/17
to Peter Gutmann, Martin Heaps
On 05/02/17 06:20, Peter Gutmann wrote:
> That's not a cert issue, it's Firefox objecting to the version of SSL/TLS the
> server is advertising. Hey, it would be pretty funny if the cert auditors'
> certs were broken, but it's just the browser complaining about something else.

That machine definitely needs a webserver upgrade.

Gerv

Gervase Markham

unread,
Feb 7, 2017, 11:08:36 AM2/7/17