Re: PROCERT issuing certificates with non-random serial numbers

[Andrew Ayer via dev-security-policy]

On Wed, 16 Aug 2017 19:56:45 -0700
Andrew Ayer via dev-security-policy
 wrote:

> Every certificate known to CT issued by PROCERT with a notBefore
> date after September 30, 2016 has what appears to be a non-random
> serial number: https://crt.sh/?Identity=%25&iCAID=750

These are now being tracked on misissued.com: https://misissued.com/batch/12/

> In addition, their OCSP responder is returning a status of "Good" for
> adjacent serial numbers, suggesting sequential assignment of serial
> numbers.

Actually, their OCSP responder is returning good for unissued
certificates, which is itself a BR violation.  I've attached a sample
OCSP response to the
bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1391058

Regards,
Andrew
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New undisclosed Camerfirma intermediates

[Aaron Wu via dev-security-policy]

Hi Jonathan,

Thanks for reminding! I've sent mail to POC of AC Camerfirma and these two 
intermediate certs has been disclosed in CCADB now.

Aaron Wu 
Mozilla Corporation
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

PROCERT issuing certificates with non-random serial numbers

[Andrew Ayer via dev-security-policy]

Every certificate known to CT issued by PROCERT with a notBefore
date after September 30, 2016 has what appears to be a non-random
serial number: https://crt.sh/?Identity=%25&iCAID=750

1e:4d:94:48:00:00:00:00:0c:79
2f:84:26:06:00:00:00:00:0b:1b
3d:94:73:d1:00:00:00:00:0a:ab
4b:53:8c:18:00:00:00:00:09:db
4c:94:f1:d5:00:00:00:00:0a:bd
4c:f3:00:86:00:00:00:00:0a:c0
4d:a7:2c:6a:00:00:00:00:0a:c3
4e:11:32:b3:00:00:00:00:0a:c7
6f:d3:c3:24:00:00:00:00:0c:56
7b:33:8f:17:00:00:00:00:0c:96
7b:98:a8:b1:00:00:00:00:0c:97
11:bb:b9:9f:00:00:00:00:0b:af
14:e9:6d:a4:00:00:00:00:0a:fa
16:8e:a3:9d:00:00:00:00:0b:f5
17:93:5a:4f:00:00:00:00:09:a6
17:96:d7:b8:00:00:00:00:09:a7
18:94:8a:f4:00:00:00:00:09:5a
18:98:dc:bb:00:00:00:00:09:5b
35:ce:d9:af:00:00:00:00:0c:02
43:ed:d4:a7:00:00:00:00:0a:b1
51:33:c5:60:00:00:00:00:0a:36
62:fa:e6:81:00:00:00:00:08:ad
69:4d:2f:c1:00:00:00:00:08:b4
76:81:87:9b:00:00:00:00:0b:65

In addition, their OCSP responder is returning a status of "Good" for
adjacent serial numbers, suggesting sequential assignment of serial
numbers.

This violates section of 7.1 of the BRs, which state:

"Effective September 30, 2016, CAs SHALL generate non-sequential
Certificate serial numbers greater than zero (0) containing at least 64
bits of output from a CSPRNG."

I have not reported this to PROCERT since their problem reporting
mechanism is a link to a non-English web page.

Regards,
Andrew
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Bugzilla Bugs re CA issuance of non-compliant certs

[Kathleen Wilson via dev-security-policy]

Bugs filed...

== Actalis ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390974

== Camerfirma ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390977

== Certinomis ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390978

== certSIGN ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390979

== Comodo ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390981

== Consorci AOC ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390988

== D-TRUST ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390990

== DigiCert ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1389172

== Disig ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390991

== DocuSign/Keynectis ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390994

== Entrust ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390996

== FNMT ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391095
(This bug is to add the AC FNMT Usuarios certificate to OneCRL)

== GlobalSign ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390997

== Kamu SM ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1390998

== IdenTrust == 
https://bugzilla.mozilla.org/show_bug.cgi?id=1391000

== Izenpe ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391054

== Let’s Encrypt == 
RESOLVED (no bug needed)

== Microsec e-Szigno ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391055

== NetLock ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391056

== PROCERT ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391058

== QuoVadis ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391063

== SECOM ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391064

== StartCom ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1386894

== Staat der Nederlandend / PKIoverheid ==
RESOLVED (no bug needed)

== SwissSign == 
https://bugzilla.mozilla.org/show_bug.cgi?id=1391066

== Symantec ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391067

== Taiwan-CA ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391068

== T-Systems ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391074

== Visa ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391087

== WISeKey ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1391089

==


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Bad characters in dNSNames

[alex.gaynor--- via dev-security-policy]

On Wednesday, August 16, 2017 at 11:22:01 AM UTC-4, Rob Stradling wrote:
> BTW, I've just asked Alex to look at adding the "CA Owner" field to the 
> misissued.com reports.  :-)
> 

It does this now :-)

Cheers,
Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: O=U.S. Government for non-USG entity (IdenTrust)

[Jonathan Rudenberg via dev-security-policy]

> On Aug 16, 2017, at 13:44, Jonathan Rudenberg via dev-security-policy 
>  wrote:
> 
> After looking into this more, I’ve found that the majority of certificates 
> issued by the "IdenTrust ACES CA 2” and "IdenTrust ACES CA 1” intermediates 
> are not BR-compliant.

If anyone is interested in looking through the expired/revoked certificates 
issued by these intermediates, these two links will show all of the 
certificates that are known to CT:

https://crt.sh/?Identity=%25&iCAID=718
https://crt.sh/?Identity=%25&iCAID=5738

After clicking on a certificate ID, you can click the “Run cablint” link on the 
left to see the cablint output.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: O=U.S. Government for non-USG entity (IdenTrust)

[Jonathan Rudenberg via dev-security-policy]

> On Aug 16, 2017, at 12:52, Jonathan Rudenberg via dev-security-policy 
>  wrote:
> 
> I looked through the CT logs and found 15 more unexpired unrevoked 
> certificates that are trusted by NSS and appear to have the same inaccurate 
> organizationName of “U.S. Government” for a non-USG entity.
> 
> The list is here: https://misissued.com/batch/10/
> 
> Can you explain why your review missed these? Are there any more in addition 
> to these 15 and previous 5?
> 
> Jonathan

After looking into this more, I’ve found that the majority of certificates 
issued by the "IdenTrust ACES CA 2” and "IdenTrust ACES CA 1” intermediates are 
not BR-compliant.

The issues fall into three categories:

1) Certificates with HTTPS OCSP URLs
2) Certificates with otherName SANs
3) Certificates that appear to be intended as client certificates, but have the 
anyExtendedKeyUsage EKU, putting them in scope for the Mozilla Root Policy.

I’ve found 33 certificates that have one or more of these issues that are 
unexpired and unrevoked.

Here is the full list: https://misissued.com/batch/11/ (note that it is a 
superset of the batch I posted earlier today)

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Bugzilla Bugs re CA issuance of non-compliant certs

[Kathleen Wilson via dev-security-policy]

I will proceed with filing these bugs now.

Kathleen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: O=U.S. Government for non-USG entity (IdenTrust)

[Jonathan Rudenberg via dev-security-policy]

> On Aug 15, 2017, at 14:53, identrust--- via dev-security-policy 
>  wrote:
> 
> On Friday, August 11, 2017 at 6:05:29 PM UTC-4, paul.l...@gmail.com wrote:
>> On Friday, August 11, 2017 at 3:43:17 PM UTC-5, iden...@gmail.com wrote:
>>> IdenTrust is fully aware of the situation and has consulted with internal 
>>> and external parties to ensure that our course of action is appropriate and 
>>> commensurate with our business practices and accommodates our customer’s 
>>> needs.
>>> When IdenTrust initially established the ACES SSL profile, it was intended 
>>> to apply only to US government entities.  At that time, the Organization 
>>> was defined as a static value of “U.S. Government” in our profiles.  Later, 
>>> when non-agencies applied, IdenTrust reasoned at that time that this static 
>>> value continued to be acceptable as these entities must identify themselves 
>>> as organizations that act as relying parties, accepting certificates issued 
>>> under the ACES program, and are in some capacity associated with the U.S. 
>>> Government.  We have discussed internally and taken a fresh look at this 
>>> decision.   As a result, IdenTrust has updated the ACES SSL profile to use 
>>> the applicant Organization name in the Subject DN organization field.  This 
>>> change will accommodate all applications for ACES SSL certificates, both 
>>> U.S. agencies and non-agencies.  At the same time, we have modified the 
>>> OCSP validation URL from HTTPS to HTTP.  
>>> It is important to note that all certificates that are impacted by this 
>>> situation have been appropriately vetted by the IdenTrust Registration team 
>>> according to Identity Validation requirements stated in the ACES CP, 
>>> therefore the need to revoke affected certificates immediately is less 
>>> critical.  Our key objective is to revoke all incorrect certificates as 
>>> quickly as possible, while minimizing the impact to our customers and 
>>> avoiding disruption to critical business processes.  As such, IdenTrust is 
>>> working directly with these customers to initiate a replacement for the 
>>> offending certificates.  The replacement process allows the client to use 
>>> an online mechanism to request a new certificate with the correct 
>>> attributes and immediately download the new certificate.  The replacement 
>>> process also automatically revokes the certificate being replaced.  This 
>>> will enable our clients to receive a newly vetted certificate and they will 
>>> not be inconvenienced by a forced revocation, which would likely adversely 
>>> impact their business processes. IdenTrust will ultimately force a 
>>> revocation, in the event that the clients do not initiate a certificate 
>>> replacement in response to our communications.
>>> 
>>> Thank you for the opportunity to represent our position.
>> 
>> Is it Identrust's contention that the revocation rules required under the 
>> requirements they are audited under do not apply to these certificates 
>> because it would inconvenience their customers? This is a clear violation of 
>> the baseline requirements and I'd like some clarity on why Identrust 
>> believes it's permissible to pick and choose what their revocation timelines 
>> will be.
>> 
>> -Paul
> No, IdenTrust is not insinuating that the revocation rules do not apply here. 
>  IdenTrust, upon notification, immediately started reviewing our historical 
> understanding of our ACES SSL program and how it complied with both the ACES 
> CP and CA/B CP. This review involving internal and external resources began 
> in earnest. As previously stipulated, all certificates impacted were 
> appropriately vetted by the IdenTrust Registration team according to Identity 
> Validation requirements stated in the ACES CP.  IdenTrust worked to bridge 
> the gap between historical definitions and CA/B forum compliance while 
> balancing the needs of the community and IdenTrust customers alike. 
> Concurrently, IdenTrust reviewed, implemented and validated programmatic 
> controls prohibiting the population of the "U.S. Government" for ACES 
> non-agency entities. Once our technical fix was verified, our priority 
> objective has been to revoke all non-compliant certificates as quickly as 
> possible, while minimizing the impact to our customers and avoiding 
> disruption to critical business processes.   IdenTrust has been working with 
> the certificate sponsors to initiate a replacement for these identified 
> certificates.  One certificate has been successfully replaced.  For one 
> certificate, the customer has requested an extension until Wednesday 
> (tomorrow) to replace--we have granted this extension, but will revoke if the 
> replacement in not completed by 5 p.m. MT on Wednesday.  For the three 
> certificates where we were not successful in facilitating a replacement, we 
> have completed a revocation.  We will confirm replacement or revocation of 
> the last remaining certificate after 5 p.m. MT tomorrow.

I looke

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[identrust--- via dev-security-policy]

On Tuesday, August 15, 2017 at 4:42:06 PM UTC-4, Eric Mill wrote:
> On Tue, Aug 15, 2017 at 2:47 PM, identrust--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > We have been moderately successful in replacing the five (5)
> > certificates.  One (1) has been voluntarily replaced, we have a commitment
> > from our client to initiate a replacement for one (1) tomorrow and three
> > (3) have been revoked by IdenTrust.
> >
> 
> Thank you for this -- this information is very helpful to the community in
> evaluating ongoing impact to clients, and in how specific issues are being
> handled beyond the expected 24-hour timespan.
> 
> -- Eric
> 
> 
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> 
> 
> 
> -- 
> konklone.com | @konklone 
IdenTrust has revoked the identified certificates: 
https://misissued.com/batch/4/.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Bad characters in dNSNames

[Jonathan Rudenberg via dev-security-policy]

> On Aug 16, 2017, at 11:37, Amus via dev-security-policy 
>  wrote:
> 
> What's wrong with the two Well's Fargo certs? I don't see any invalid 
> characters in them.

https://crt.sh/?opt=cablint&id=19558707
https://crt.sh/?opt=cablint&id=11382596

Both have trailing spaces in one of the dnsNames: "ceomobilefix.wf.com “ and 
"ceomobile.wf.com “

Note that they are also expired.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Bad characters in dNSNames

[Amus via dev-security-policy]

What's wrong with the two Well's Fargo certs? I don't see any invalid 
characters in them.

On Wednesday, August 16, 2017 at 9:22:01 AM UTC-6, Rob Stradling wrote:
> On 15/08/17 13:29, Gervase Markham via dev-security-policy wrote:
> > Hi Rob,
> > 
> > On 26/07/17 11:21, Rob Stradling wrote:
> >> https://docs.google.com/spreadsheets/d/1IACTYMDXcdz4DoMKxkHfePfb5mv2XN68BcB7p6acTqg/edit?usp=sharing
> > 
> > Thanks for this. Any chance of saving me a bit of time by
> > cross-referencing each line with the "CA owner" from the CCADB? If
> > that's too much work, no problem, let me know and I can do it myself by
> > hand.
> 
> Hi Gerv.  I've just added the "CA Owner" field to both tabs on this 
> spreadsheet.  See also https://misissued.com/batch/3/, which reports on 
> the same set of certificates.
> 
> BTW, I've just asked Alex to look at adding the "CA Owner" field to the 
> misissued.com reports.  :-)
> 
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Bad characters in dNSNames

[Rob Stradling via dev-security-policy]

On 15/08/17 13:29, Gervase Markham via dev-security-policy wrote:

Hi Rob,

On 26/07/17 11:21, Rob Stradling wrote:

https://docs.google.com/spreadsheets/d/1IACTYMDXcdz4DoMKxkHfePfb5mv2XN68BcB7p6acTqg/edit?usp=sharing


Thanks for this. Any chance of saving me a bit of time by
cross-referencing each line with the "CA owner" from the CCADB? If
that's too much work, no problem, let me know and I can do it myself by
hand.


Hi Gerv.  I've just added the "CA Owner" field to both tabs on this 
spreadsheet.  See also https://misissued.com/batch/3/, which reports on 
the same set of certificates.


BTW, I've just asked Alex to look at adding the "CA Owner" field to the 
misissued.com reports.  :-)


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

[Arno Fiedler via dev-security-policy]

Am Dienstag, 15. August 2017 16:21:03 UTC+2 schrieb Gervase Markham:
> On 14/08/17 16:44, Arno Fiedler wrote:
> > fulfilled. On 20-07-17 Mozilla asked D-TRUST for clarification, due
> > to the holiday period this message reached us on 07-08-17, AF
> > answered on 08-08-17
> 
> I was going to complain about this but, re-reviewing the CCADB Common
> Policy[0], it says:
> 
> "Notification of security and audit-related issues will be emailed to
> all POCs and the email aliases; CAs are advised to supply sufficient
> POCs that will enable them to respond to an issue promptly."
> 
> As I only sent the notification to Arno alone (the primary PoC) then I
> have to take responsibility for not providing sufficient notification.
> My apologies.
> 
> Gerv
> 
> [0] http://ccadb.org/policy

We really genuinely regret the delayed reaction, today we add the non-personal 
contact email
"rootsto...@d-trust.net"
that should improve the process.

Arno 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificate with invalid dnsName issued from Baltimore intermediate

[Ben Wilson via dev-security-policy]

Attached is an audit from 2016.  They are due for another one for 2017.

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
Sent: Tuesday, August 15, 2017 6:55 AM
To: Ben Wilson ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName issued from Baltimore
intermediate

Hi Ben,

On 03/08/17 15:38, Ben Wilson wrote:
> Here is the response from Intesa Sanpaolo concerning the disruption
> that revocation will cause to their banking operations:

I've looked up the certs relating to this sub-CA in the CCADB. The key in
question:

https://crt.sh/?caid=1698&opt=cablint,x509lint

appears to be in two certs, which are:

https://crt.sh/?id=18068159&opt=cablint,x509lint
and
https://crt.sh/?id=6158202&opt=cablint,x509lint

They have CCADB entries here (note: these links work for me, but AIUI CA links
are different):

https://ccadb.my.salesforce.com/001o00dsANG
https://ccadb.my.salesforce.com/001o00dsAlD

The audit fields for both of these say "Available on request". I'm not sure
that's a valid value for that field; it's supposed to link to the actual
audit. Nevertheless, I am now requesting. Can you please provide the audits
for this subCA?

Thanks,

Gerv



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