Re: Maximal validity of the test TLS certificate issued by a private PKI system
My opinion:
The CA/B Forum Baseline Requirements only apply to certificates which chain to
publicly trusted roots. This is made clear in the preamble of the document:
This document describes an integrated set of technologies, protocols,
identity-proofing, lifecycle management, and auditing requirements that are
necessary (but not sufficient) for the issuance and management of
Publicly-Trusted Certificates; Certificates that are trusted by virtue of the
fact that their corresponding Root Certificate is distributed in
widely-available application software.
The BRs do not apply to certificate issuance from non publicly trusted
hierarchies.
Dean CoclinCA/B Forum Vice-Chair
-Original Message-
From: Sándor dr. Szőke via dev-security-policy
To: mozilla-dev-security-policy
Sent: Thu, Dec 13, 2018 1:36 pm
Subject: Maximal validity of the test TLS certificate issued by a private PKI
system
It is not absolutely clear for us how to manage the test certificates which
were issued by a CA where there are no certificate chains to a root certificate
subject to the Baseline Requirements (for example an independent test CA
hierarchy).
The BR wording is as follows:
Test Certificate: A Certificate with a maximum validity period of 30 days and
which: (i) includes a critical
extension with the specified Test Certificate CABF OID (2.23.140.2.1), or (ii)
is issued under a CA where there
are no certificate paths/chains to a root certificate subject to these
Requirements.
I can interpret the definition in two different ways:
1. by using the listing as a parenthesis, so
Test Certificate:
A Certificate
{with a maximum validity period of 30 days}
AND
which:
{
(i) includes a critical extension with the specified Test Certificate CABF OID
(2.23.140.2.1),
OR
(ii) is issued under a CA where there are no certificate paths/chains to a root
certificate subject to these Requirements.
}
So it means that any test certificate shall have the validity max. 30 days,
AND
we have two possibilities:
(i) if the test certificate issued under a CA where there is a certificate
chain to a root certificate subject to the BR, then the test certificate shall
include the critical extension with the specified Test Certificate CABF OID
(2.23.140.2.1)
(ii) if the test certificate is issued under a CA where there are no
certificate chains to a root certificate subject to the BR, then there is no
further requirement.
Question:
if this interpretation is correct, then why do we have a requirement to limit
the validity period of the test certificate for 30 days, if the issuer CA is
out of the scope of the BR?
2. by thinking as an engineer, where the AND operation is higher level than the
OR, the separation looks like this:
Test Certificate:
A Certificate
{
with a maximum validity period of 30 days
AND
which:
(i) includes a critical extension with the specified Test Certificate CABF OID
(2.23.140.2.1),
}
OR
{
(ii) is issued under a CA where there are no certificate paths/chains to a root
certificate subject to these Requirements.
}
So it means, that
(i) if the test certificate issued under a CA where there is a certificate
chain to a root certificate subject to the BR, then the test certificate shall
include the critical extension with the specified Test Certificate CABF OID
(2.23.140.2.1) AND the validity period of the test certificate is maximum 30
days
(ii) if the test certificate is issued under a CA where there are no
certificate chains to a root certificate subject to the BR, then there is no
any further requirement
In this interpretation the wording seems to be strange, but the requirement
seems to be more realistic and clear.
Which interpretation is correct?
Is it allowed to issue test TLS certificates in an independent test system with
more than 30 days validity?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Underscore characters and DigiCert
Hey all, We're working towards revoking certs with underscore characters in the domain name, per SC12, but I had a question about legacy Symantec systems and Mozilla. These particular roots are no longer trusted for TLS certs in Google or Mozilla, which means the applicability of the BRs is dubious. The roots are shortly being removed from Microsoft and Apple, although that's more of an FYI rather than something with direct bearing on the Mozilla community. If the roots are no longer trusted for TLS in Mozilla, is there any requirement to revoke the certs issued under those roots? My initial thought is no as this is similar to what Comodo did with their request to remove a SHA1 root (and what DigiCert did with one of the Verizon roots). Note these are still flagged by zlint because they are trusted in older systems. Because the situation is slightly different with the way distrust was technically implemented, I wanted to see if there were any concerns with the community about treating these as private going forward, similar to the SHA1 roots. Thoughts? Jeremy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3
I have update the bug [1] and recommended approval of this emSign root inclusion request. - Wayne [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1442337 On Tue, Nov 27, 2018 at 10:19 AM Wayne Thayer wrote: > I've reviewed the updated CPS and these period-of-time audit statements - > I have no concerns with them. > > I believe that emSign has also addressed all the other comments that have > been made on this request. > > Unless additional concerns are raised, I plan to end this discussion on > Friday 30-November. > > - Wayne > >> >> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Maximal validity of the test TLS certificate issued by a private PKI system
On Wed, Dec 12, 2018 at 9:13 AM Sándor dr. Szőke via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Thank you for the detailed answer, I think that the requirement is clear > for us now. > > The misunderstanding was caused by the different usage of the term 'Test > Certificate'. > > The 'Test Certificate' in the BR means a certificate, which is used for > domain validation according to the 3.2.2.4.9. This case it is fully > understandable to limit the validity of the test certificate because it is > in line with other validation methods. > > Correct. Microsec doesn't use this validation method and never issues this type of > test certificates. > > The test certificate in our practice means a certificate which is issued > in a TEST CA which is not included in the CCADB. These test certificates > are typically requested by software developers to develop their software > products which will work with X509 certificates. > > I think that these type of test certificates are out of the scope of the > BR. > > This is generally correct. Section 1.1 limits the scope of the BRs to "Certificates that are trusted by virtue of the fact that their corresponding Root Certificate is distributed in widely-available application software." Mozilla policy section 7.1 states the following: Before being included, CAs MUST provide evidence that their CA certificates have continually, from the time of creation, complied with the then-current Mozilla Root Store Policy and Baseline Requirements. This means that "test" certificates chaining to a root that will in the future be submitted for inclusion in the Mozilla program must comply with the BRs, even if the root is not in CCADB or Mozilla's program when the "test" certificates are issued. In other words, the "test" certificates that you are describing must be signed by a CA certificate and chain to a root that exist solely for the purpose of issuing "test" certificates. > > Is it correct? > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Maximal validity of the test TLS certificate issued by a private PKI system
2018. december 11., kedd 19:51:45 UTC+1 időpontban Doug Beattie a következőt
írta:
> Option 1 is the intended interpretation. We specified 30 days because the
> tokens used for domain validation (Random Number) need to have a useful life
> of 30 days. The 30-day usage period needed to be put into the definition of
> the Test Certificate, or into Method 3.2.2.4.9, and we selected the validity
> period as the means to convey this requirement.
>
> Note that Method 9 has identified security issues as it relates to shared IP
> addresses, so currently it's not permitted to be used (according to Google),
> even though it remains in the BRs. It should be updated or removed. Method
> 10 has similar issues which are being mitigated with ALPN approach, but no
> work has been done on Method 9 in this regard.
>
> Doug
>
>
> -Original Message-
> From: dev-security-policy On
> Behalf Of Sándor dr. Szoke via dev-security-policy
> Sent: Tuesday, December 11, 2018 1:24 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Maximal validity of the test TLS certificate issued by a private
> PKI system
>
>
> It is not absolutely clear for us how to manage the test certificates which
> were issued by a CA where there are no certificate chains to a root
> certificate subject to the Baseline Requirements (for example an independent
> test CA hierarchy).
>
> The BR wording is as follows:
>
> Test Certificate: A Certificate with a maximum validity period of 30 days
> and which: (i) includes a critical extension with the specified Test
> Certificate CABF OID (2.23.140.2.1), or (ii) is issued under a CA where
> there are no certificate paths/chains to a root certificate subject to these
> Requirements.
>
>
> I can interpret the definition in two different ways:
>
> 1. by using the listing as a parenthesis, so
>
> Test Certificate:
> A Certificate
> {with a maximum validity period of 30 days} AND
> which:
> {
> (i) includes a critical extension with the specified Test Certificate CABF
> OID (2.23.140.2.1), OR
> (ii) is issued under a CA where there are no certificate paths/chains to a
> root certificate subject to these Requirements.
> }
>
> So it means that any test certificate shall have the validity max. 30 days,
> AND we have two possibilities:
> (i) if the test certificate issued under a CA where there is a certificate
> chain to a root certificate subject to the BR, then the test certificate
> shall include the critical extension with the specified Test Certificate
> CABF OID (2.23.140.2.1)
> (ii) if the test certificate is issued under a CA where there are no
> certificate chains to a root certificate subject to the BR, then there is no
> further requirement.
>
> Question:
>
> if this interpretation is correct, then why do we have a requirement to
> limit the validity period of the test certificate for 30 days, if the issuer
> CA is out of the scope of the BR?
>
>
>
> 2. by thinking as an engineer, where the AND operation is higher level than
> the OR, the separation looks like this:
>
> Test Certificate:
> A Certificate
> {
> with a maximum validity period of 30 days AND
> which:
> (i) includes a critical extension with the specified Test Certificate CABF
> OID (2.23.140.2.1), } OR {
> (ii) is issued under a CA where there are no certificate paths/chains to a
> root certificate subject to these Requirements.
> }
>
> So it means, that
> (i) if the test certificate issued under a CA where there is a certificate
> chain to a root certificate subject to the BR, then the test certificate
> shall include the critical extension with the specified Test Certificate
> CABF OID (2.23.140.2.1) AND the validity period of the test certificate is
> maximum 30 days
> (ii) if the test certificate is issued under a CA where there are no
> certificate chains to a root certificate subject to the BR, then there is no
> any further requirement
>
> In this interpretation the wording seems to be strange, but the requirement
> seems to be more realistic and clear.
>
> Which interpretation is correct?
>
> Is it allowed to issue test TLS certificates in an independent test system
> with more than 30 days validity?
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
Thank you for the detailed answer, I think that the requirement is clear for us
now.
The misunderstanding was caused by the different usage of the term 'Test
Certificate'.
The 'Test Certificate' in the BR means a certificate, which is used for domain
validation according to the 3.2.2.4.9. This case it is fully understandable to
limit the validity of the test certificate because it is in line with other
validation methods.
Microsec doesn't use this validation method and never issues this type of test
certificates.
The test certificate in our practice means a certificate
RE: SSL private key for *.alipcsec.com embedded in PC client executables
As a follow-up, The certificate was revoked about 2 hours ago:
https://crt.sh/?id=300288180=ocsp
-Original Message-
From: Doug Beattie
Sent: Tuesday, December 11, 2018 8:09 AM
To: 'dev-security-policy@lists.mozilla.org'
Cc: 'Xiaoyin Liu' ; Mark Steward
Subject: RE: SSL private key for *.alipcsec.com embedded in PC client
executables
Thank you for this report. We've verified disclosure of the private key for
this certificate and have notified the customer that their certificate will
be revoked. Due to the large customer impact, we're provided them 24 hours
to get new client executables prepared and ready for download by their
customers. We'll post a message when the certificate has been revoked.
https://crt.sh/?id=300288180
Doug
-Original Message-
From: dev-security-policy On
Behalf Of Xiaoyin Liu via dev-security-policy
Sent: Tuesday, December 11, 2018 6:52 AM
To: Mark Steward
Cc: dev-security-policy@lists.mozilla.org
Subject: Re: SSL private key for *.alipcsec.com embedded in PC client
executables
Thank you for your helpful reply, Mark! Finally I found the key in memory
too.
I sent another report with the private key to Alibaba. Hopefully they will
take actions. If Alibaba doesn't reply me tomorrow, I will report to
GlobalSign.
Best,
Xiaoyin
From: Mark Steward
Sent: Tuesday, December 11, 2018 3:24:21 PM
To: xiaoyi...@outlook.com
Cc: dev-security-policy@lists.mozilla.org
Subject: Re: SSL private key for *.alipcsec.com embedded in PC client
executables
This time it's just hanging around in memory, no need to do anything about
the anti-debug.
$ openssl x509 -noout -modulus -in 300288180.crt|md5sum
f423a009387fb7a306673b517ed4f163 -
$ openssl rsa -noout -modulus -in alibaba-localhost.key.pem|md5sum
f423a009387fb7a306673b517ed4f163 -
You can verify that I've signed lorem ipsum with the following:
$ wget https://crt.sh/?d=300288180 -O 300288180.crt $ wget
https://rack.ms/b/UsNQv74sfH40/msg.txt{,.sig-sha256.b64}
$ openssl dgst -sha256 -verify <(openssl x509 -in 300288180.crt -pubkey
-noout) -signature <(base64 -d msg.txt.sig-sha256.b64) msg.txt
As the domain name suggests, this is part of the AlibabaProtect/"Alibaba PC
Safe Service" that comes bundled with the Youku client.
Mark
Mark
On Tue, Dec 11, 2018 at 5:37 AM Xiaoyin Liu via dev-security-policy
wrote:
>
> Hello,
>
> I think I found a SSL certificate misuse issue, but I am not sure if this
is indeed a misuse, so I want to ask about it on this list.
>
> Here is the issue: After I installed Youku Windows client
(https://pd.youku.com/pc, installer:
https://pcclient.download.youku.com/youkuclient/youkuclient_setup_7.6.7.1122
0.exe), it starts a local HTTPS server, listening on localhost:6691. Output
of "openssl s_client -connect 127.0.0.1:6691" indicates that this local
server uses a valid SSL certificate, issued to "Alibaba (China) Technology
Co., Ltd." CN=*.alipcsec.com, and issued by GlobalSign. It's a publicly
trusted OV cert, and is valid until Jan 13, 2019. Later, I found that
local.alipcsec.com resolves to 127.0.0.1, and
https://local.alipcsec.com:6691/ is used for inter-process communication.
>
> It's clear that the private key for *.alipcsec.com is embedded in the
executable, but all the executables that may embed the private key are
packed by VMProtect, and the process has anti-debugging protection. I tried
plenty of methods to extract the private key, but didn't succeed. I reported
this to Alibaba SRC anyway. They replied that they ignore this issue unless
I can successfully extract the key.
>
> So is this a certificate misuse issue, even if the private key is
obfuscated? If so, do I have to extract the private key first before the CA
can revoke the cert?
>
> Thank you!
>
> Best,
> Xiaoyin Liu
>
> Here is the certificate:
> -BEGIN CERTIFICATE-
> MIIHTjCCBjagAwIBAgIMCpI/GtuuSFspBu4EMA0GCSqGSIb3DQEBCwUAMGYxCzAJ
> BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTwwOgYDVQQDEzNH
> bG9iYWxTaWduIE9yZ2FuaXphdGlvbiBWYWxpZGF0aW9uIENBIC0gU0hBMjU2IC0g
> RzIwHhcNMTgwMTEyMDgxMTA1WhcNMTkwMTEzMDgxMTA1WjB7MQswCQYDVQQGEwJD
> TjERMA8GA1UECBMIWmhlSmlhbmcxETAPBgNVBAcTCEhhbmdaaG91MS0wKwYDVQQK
> EyRBbGliYWJhIChDaGluYSkgVGVjaG5vbG9neSBDby4sIEx0ZC4xFzAVBgNVBAMM
> DiouYWxpcGNzZWMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
> 9PJcPzpUNRJeA8+YF8cRZEn75q+fSsWWkm6JfIlOKorYXwYJB80de4+Bia3AgzfO
> wqwWfPGrRYh5OY4ujjsKF5XkWG22SLlzi5xB9zAeVKHYTo2U6aKrKnht9XyYvnZX
> ocIuaSxkqq4rQ9UwiEYB6lvy8RY1orYu33HtrGD5W3w9SWf2AwB0rCNp0BeSRaGB
> JEEXzgVECbL+deJZgZflae1gQ9q4PftDHuGXLNe8PLYq2D4+oKbYvbYtI9WKIMuh
> 1dL70QBbcW0y4jFr2/337H8/KhBaCb3ZBZQI4LUnYL8RVeAVJFpX/PuiHMh9uNTm
> oW1if7XQswJCWx3td5tWiwIDAQABo4ID5TCCA+EwDgYDVR0PAQH/BAQDAgWgMIGg
> BggrBgEFBQcBAQSBkzCBkDBNBggrBgEFBQcwAoZBaHR0cDovL3NlY3VyZS5nbG9i
> YWxzaWduLmNvbS9jYWNlcnQvZ3Nvcmdhbml6YXRpb252YWxzaGEyZzJyMS5jcnQw
> PwYIKwYBBQUHMAGGM2h0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9nc29yZ2Fu
>
