Re: Certificate with invalid dnsName

2017-07-19 Thread Charles Reiss via dev-security-policy 

On 07/19/2017 06:03 PM, Tom wrote:

Following that discovery, I've search for odd (invalid?) DNS names.
Here is the list of certificated I've found, it may overlap some 
discovery already reported.
If I'm correct, theses certificate are not revoked, not expired, and 
probably trusted by Mozilla (crt.sh issuer are marked trusted by 
Mozilla, but not all).


Annotating these certs:


Starting with *:


I believe this cert is presently untrusted by Mozilla due to revocation 
of all paths to the Federal PKI:

https://crt.sh/?id=7211484*eis.aetc.af.mil


chains to StartCom (and all of these from StartCom are minor compared to 
StartCom's other problems):

https://crt.sh/?id=10714112*g10.net-lab.net


chains to Baltimore CyberTrust Root (DigiCert):

https://crt.sh/?id=48682944*nuvolaitaliana.it


chains to StartCom:

https://crt.sh/?id=15736178*assets.blog.cn.net.ru
https://crt.sh/?id=17295812*dev02.calendar42.com
https://crt.sh/?id=15881220*dev.1septem.ru
https://crt.sh/?id=15655700*assets.blog.cn.net.ru
https://crt.sh/?id=17792808*quickbuild.raptorengineering.io





Starting with -:


chains to QuoVadis:
https://crt.sh/?id=54285413
-d1-datacentre-12g-console-2.its.deakin.edu.au


chains to StartCom:

https://crt.sh/?id=78248795-1ccenter.777chao.com





Multiple *.:


chains to QuoVadis:

https://crt.sh/?id=13299376*.*.victoria.ac.nz


I believe this cert is presently trusted by Mozilla only via a 
technically constrained subCA:

https://crt.sh/?id=44997156*.*.rnd.unicredit.it


chains to Swisscom:

https://crt.sh/?id=5982951*.*.int.swisscom.ch





Internals TLD:


chains to Baltimore CyberTrust Root (DigiCert):

https://crt.sh/?id=33626750a1.verizon.test


I believe this cert is presently untrusted by Mozilla due to revocation 
of the relevant subCA:

https://crt.sh/?id=33123653DAC38997VPN2001A.trmk.corp


chains to Certplus (DocuSign):

https://crt.sh/?id=42475510naccez.us.areva.corp


I believe these presently lack an unrevoked, unexpired trust path in 
Mozilla:

https://crt.sh/?id=10621703collaboration.intra.airbusds.corp
https://crt.sh/?id=48726306zdeasaotn01.dsmain.ds.corp

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

RE: Certificate with invalid dnsName

2017-07-19 Thread Jeremy Rowley via dev-security-policy 
Thank you, Charles and Tom, for bringing this to the forefront.  We have
contacted the cross-signed partner and asked for an explanation. We've also
demanded revocation within 24 hours and a full scan to determine whether any
other certificates exist.  

Jeremy 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Charles Reiss via dev-security-policy
Sent: Wednesday, July 19, 2017 7:02 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName

On 07/19/2017 06:03 PM, Tom wrote:
> Following that discovery, I've search for odd (invalid?) DNS names.
> Here is the list of certificated I've found, it may overlap some 
> discovery already reported.
> If I'm correct, theses certificate are not revoked, not expired, and 
> probably trusted by Mozilla (crt.sh issuer are marked trusted by 
> Mozilla, but not all).
> 
[snip]

Some additional problematic certs:

chains to Swisscom:
https://crt.sh/?id=175444569  wxadm.swissucc.local

chains to CATCert, notBefore in 2017:
https://crt.sh/?id=98706307   maritim4.mmaritim.local

chains to PROCERT, notBefore in 2017:
https://crt.sh/?id=175466182  fospuca.local

chains to Baltimore Cybertrust Root (DigiCert):
https://crt.sh/?id=12344381   lorweb.local

chains to Baltimore Cybertrust Root (DigiCert), notBefore in 2017:
https://crt.sh/?id=175469208  skbfep01.justica.local
https://crt.sh/?id=175469209  energy.ctd  and  pt

chains to QuoVadis, notBefore in 2017:
https://crt.sh/?id=175466199  devsrv.pe.siemens.info-com  (swapped -/.)

chains to DocuSign, notBefore in 2017:
https://crt.sh/?id=99149574   "www.immonotaireargus.com " (trailing space)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


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: Certificate with invalid dnsName

2017-07-19 Thread Charles Reiss via dev-security-policy 

On 07/19/2017 06:03 PM, Tom wrote:

Following that discovery, I've search for odd (invalid?) DNS names.
Here is the list of certificated I've found, it may overlap some 
discovery already reported.
If I'm correct, theses certificate are not revoked, not expired, and 
probably trusted by Mozilla (crt.sh issuer are marked trusted by 
Mozilla, but not all).



[snip]

Some additional problematic certs:

chains to Swisscom:
https://crt.sh/?id=175444569  wxadm.swissucc.local

chains to CATCert, notBefore in 2017:
https://crt.sh/?id=98706307   maritim4.mmaritim.local

chains to PROCERT, notBefore in 2017:
https://crt.sh/?id=175466182  fospuca.local

chains to Baltimore Cybertrust Root (DigiCert):
https://crt.sh/?id=12344381   lorweb.local

chains to Baltimore Cybertrust Root (DigiCert), notBefore in 2017:
https://crt.sh/?id=175469208  skbfep01.justica.local
https://crt.sh/?id=175469209  energy.ctd  and  pt

chains to QuoVadis, notBefore in 2017:
https://crt.sh/?id=175466199  devsrv.pe.siemens.info-com  (swapped -/.)

chains to DocuSign, notBefore in 2017:
https://crt.sh/?id=99149574   "www.immonotaireargus.com " (trailing space)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

2017-07-19 Thread Charles Reiss via dev-security-policy 

On 07/19/2017 05:10 AM, Aaron Wu wrote:

- Tunisian Server Certificate Authority - TunServerCA2


https://crt.sh/?id=79470561=cablint is a certificate for the 
internal name 'adv-mail.calladvance.local' issued by this CA with a 
notBefore of 2017.

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

Re: Certificate with invalid dnsName

2017-07-19 Thread Tom via dev-security-policy 

Following that discovery, I've search for odd (invalid?) DNS names.
Here is the list of certificated I've found, it may overlap some 
discovery already reported.
If I'm correct, theses certificate are not revoked, not expired, and 
probably trusted by Mozilla (crt.sh issuer are marked trusted by 
Mozilla, but not all).


Starting with *:
https://crt.sh/?id=7211484  *eis.aetc.af.mil
https://crt.sh/?id=10714112 *g10.net-lab.net
https://crt.sh/?id=48682944 *nuvolaitaliana.it
https://crt.sh/?id=15736178 *assets.blog.cn.net.ru
https://crt.sh/?id=17295812 *dev02.calendar42.com
https://crt.sh/?id=15881220 *dev.1septem.ru
https://crt.sh/?id=15655700 *assets.blog.cn.net.ru
https://crt.sh/?id=17792808 *quickbuild.raptorengineering.io

Starting with -:
https://crt.sh/?id=54285413 -d1-datacentre-12g-console-2.its.deakin.edu.au
https://crt.sh/?id=78248795 -1ccenter.777chao.com

Multiple *.:
https://crt.sh/?id=13299376 *.*.victoria.ac.nz
https://crt.sh/?id=44997156 *.*.rnd.unicredit.it
https://crt.sh/?id=5982951  *.*.int.swisscom.ch

Internals TLD:
https://crt.sh/?id=33626750 a1.verizon.test
https://crt.sh/?id=33123653 DAC38997VPN2001A.trmk.corp
https://crt.sh/?id=42475510 naccez.us.areva.corp
https://crt.sh/?id=10621703 collaboration.intra.airbusds.corp
https://crt.sh/?id=48726306 zdeasaotn01.dsmain.ds.corp

Are CAs allowed to deliver such certificates?

(Methodology: https://blog.tdelmas.ovh/crt-sh/ with the links for 
expired/revoked certificates)

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

Re: [EXT] Symantec Update on SubCA Proposal

2017-07-19 Thread Eric Mill via dev-security-policy 
On Wed, Jul 19, 2017 at 11:31 AM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > Jakob Bohm via dev-security-policy
> > Sent: Tuesday, July 18, 2017 4:39 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: Re: [EXT] Symantec Update on SubCA Proposal
> >
> >
> > Just for clarity:
> >
> > (Note: Using ISO date format instead of ambiguous local date format)
> >
> > How many Symantec certs issued prior to 2015-06-01 expire after 2018-
> > 06-01, and how does that mesh with the alternative date proposed
> > below:
> >
> > On 18/07/2017 21:37, Steve Medin wrote:
> > > Correction: Summary item #3 should read:
> > >
> > > 3. May 1, 2018
> > > a. Single date of distrust of certificates issued prior to
> 6/1/2016.
> > (changed from August 31,2017 for certificates issued prior to 6/1/2015
> and
> > from January 18, 2018 for certificates issued prior to 6/1/2016).
> > >
>
> Over 34,000 certificates were issued prior to 2015-06-01 and expire after
> 2018-06-01. This is in addition to almost 200,000 certificates that would
> also need to be replaced under the current SubCA proposal assuming a May 1,
> 2018 distrust date. We believe that nine months (from August 1, 2017 to May
> 1, 2018) is aggressive but achievable for this transition — a period
> minimally necessary to allow for site operators to plan and execute an
> orderly transition and to reduce the potential risk of widespread ecosystem
> disruption. Nevertheless, we urge the community to consider moving the
> proposed May 1, 2018 distrust date out even further to February 1, 2019 in
> order to minimize the risk of end user disruption by ensuring that website
> operators have a reasonable timeframe to plan and deploy replacement
> certificates.
>

That's pretty close to saying that nothing should happen, since almost all
the certificates will have expired by then. That certainly is the least
disruptive, but it seems contrary to the intent of the proposal.

-- Eric


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



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

Re: [EXT] Symantec Update on SubCA Proposal

2017-07-19 Thread David E. Ross via dev-security-policy 
On 7/19/2017 8:31 AM, Steve Medin wrote:
>> -Original Message-
>> From: dev-security-policy [mailto:dev-security-policy-
>> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
>> Jakob Bohm via dev-security-policy
>> Sent: Tuesday, July 18, 2017 4:39 PM
>> To: mozilla-dev-security-pol...@lists.mozilla.org
>> Subject: Re: [EXT] Symantec Update on SubCA Proposal
>>
>>
>> Just for clarity:
>>
>> (Note: Using ISO date format instead of ambiguous local date format)
>>
>> How many Symantec certs issued prior to 2015-06-01 expire after 2018-
>> 06-01, and how does that mesh with the alternative date proposed
>> below:
>>
>> On 18/07/2017 21:37, Steve Medin wrote:
>>> Correction: Summary item #3 should read:
>>>
>>> 3. May 1, 2018
>>> a. Single date of distrust of certificates issued prior to 6/1/2016.
>> (changed from August 31,2017 for certificates issued prior to 6/1/2015 and
>> from January 18, 2018 for certificates issued prior to 6/1/2016).
>>>
> 
> Over 34,000 certificates were issued prior to 2015-06-01 and expire after 
> 2018-06-01. This is in addition to almost 200,000 certificates that would 
> also need to be replaced under the current SubCA proposal assuming a May 1, 
> 2018 distrust date. We believe that nine months (from August 1, 2017 to May 
> 1, 2018) is aggressive but achievable for this transition — a period 
> minimally necessary to allow for site operators to plan and execute an 
> orderly transition and to reduce the potential risk of widespread ecosystem 
> disruption. Nevertheless, we urge the community to consider moving the 
> proposed May 1, 2018 distrust date out even further to February 1, 2019 in 
> order to minimize the risk of end user disruption by ensuring that website 
> operators have a reasonable timeframe to plan and deploy replacement 
> certificates.
> 

It appears that Symantec wants to delay distrusting certificates until
all existing subscriber certificates reach their inherent expiration
dates.

-- 
David Ross


President Trump now denies there are any tapes that
recorded his conversations with ex-FBI Director Comey.
Between when Trump hinted there might be such tapes
and his denial, there was sufficient time to destroy
any tapes.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [EXT] Symantec Update on SubCA Proposal

2017-07-19 Thread Jakob Bohm via dev-security-policy 

On 19/07/2017 17:31, Steve Medin wrote:

-Original Message-
From: dev-security-policy [mailto:dev-security-policy-
bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
Jakob Bohm via dev-security-policy
Sent: Tuesday, July 18, 2017 4:39 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: [EXT] Symantec Update on SubCA Proposal


Just for clarity:

(Note: Using ISO date format instead of ambiguous local date format)

How many Symantec certs issued prior to 2015-06-01 expire after 2018-
06-01, and how does that mesh with the alternative date proposed
below:

On 18/07/2017 21:37, Steve Medin wrote:

Correction: Summary item #3 should read:

3. May 1, 2018
 a. Single date of distrust of certificates issued prior to 6/1/2016.

(changed from August 31,2017 for certificates issued prior to 6/1/2015 and
from January 18, 2018 for certificates issued prior to 6/1/2016).




Over 34,000 certificates were issued prior to 2015-06-01 and expire after 
2018-06-01. This is in addition to almost 200,000 certificates that would also 
need to be replaced under the current SubCA proposal assuming a May 1, 2018 
distrust date. We believe that nine months (from August 1, 2017 to May 1, 2018) 
is aggressive but achievable for this transition — a period minimally necessary 
to allow for site operators to plan and execute an orderly transition and to 
reduce the potential risk of widespread ecosystem disruption. Nevertheless, we 
urge the community to consider moving the proposed May 1, 2018 distrust date 
out even further to February 1, 2019 in order to minimize the risk of end user 
disruption by ensuring that website operators have a reasonable timeframe to 
plan and deploy replacement certificates.



So when and why did Symantec issue 34,000 WebPKI certificates valid
longer than 3 years, that would expire after 2018-06-01 ?

Are these certificates issued before 2015-04-01 with validity periods
longer than 39 months?

Are they certificates issued under "special circumstances" ?

Are they certificates with validity periods between 36 and 39 months?




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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [EXT] Symantec Update on SubCA Proposal

2017-07-19 Thread Steve Medin via dev-security-policy 
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Jakob Bohm via dev-security-policy
> Sent: Tuesday, July 18, 2017 4:39 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: [EXT] Symantec Update on SubCA Proposal
>
>
> Just for clarity:
>
> (Note: Using ISO date format instead of ambiguous local date format)
>
> How many Symantec certs issued prior to 2015-06-01 expire after 2018-
> 06-01, and how does that mesh with the alternative date proposed
> below:
>
> On 18/07/2017 21:37, Steve Medin wrote:
> > Correction: Summary item #3 should read:
> >
> > 3. May 1, 2018
> > a. Single date of distrust of certificates issued prior to 6/1/2016.
> (changed from August 31,2017 for certificates issued prior to 6/1/2015 and
> from January 18, 2018 for certificates issued prior to 6/1/2016).
> >

Over 34,000 certificates were issued prior to 2015-06-01 and expire after 
2018-06-01. This is in addition to almost 200,000 certificates that would also 
need to be replaced under the current SubCA proposal assuming a May 1, 2018 
distrust date. We believe that nine months (from August 1, 2017 to May 1, 2018) 
is aggressive but achievable for this transition — a period minimally necessary 
to allow for site operators to plan and execute an orderly transition and to 
reduce the potential risk of widespread ecosystem disruption. Nevertheless, we 
urge the community to consider moving the proposed May 1, 2018 distrust date 
out even further to February 1, 2019 in order to minimize the risk of end user 
disruption by ensuring that website operators have a reasonable timeframe to 
plan and deploy replacement certificates.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [EXT] Symantec Update on SubCA Proposal

2017-07-19 Thread Alex Gaynor via dev-security-policy 
Hi Steve,

Thank you for this update on Symantec's progress. I have a few follow-up
questions:

1) Did any of the RFP respondents indicate that they could provide the
Managed
   CA solution in the timeframe originally proposed by Google? (August 8th)
   Alternatively, is December 1st, 2017 the earliest date that any RFP
   respondents can achieve?

2) What selection criteria is Symantec using in considering RFP responses?

3) On June 1st, Symantec wrote that "we are in the midst of a rigorous RFP
   process"
   (
https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal
).
   In this mail you wrote that "Last month, we released a Request for
Proposal
   (RFP)". How do you reconcile those?

4) There are currently rumors that Symantec is considering a sale of its CA
   business
   (https://www.reuters.com/article/us-symantec-divestiture-idUSKBN19W2WI).
Do
   these timelines reflect that possibility, or should we expect requests to
   amend this timeline in the event of a change of ownership?

Thank you,
Alex

On Tue, Jul 18, 2017 at 3:37 PM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Correction: Summary item #3 should read:
>
> 3. May 1, 2018
>a. Single date of distrust of certificates issued prior to 6/1/2016.
> (changed from August 31,2017 for certificates issued prior to 6/1/2015 and
> from January 18, 2018 for certificates issued prior to 6/1/2016).
>
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > Steve Medin via dev-security-policy
> > Sent: Tuesday, July 18, 2017 2:23 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: [EXT] Symantec Update on SubCA Proposal
> >
> > *Progress Update on SubCA RFP, Partner Selection, and Execution*
> >
> >
> >
> > Since June 1, Symantec has worked in earnest to operationalize the SubCA
> > proposal outlined by Google and Mozilla and discussed in community
> > forums.  The core of this proposal is to transfer the authentication and
> > issuance of certificates to a set of new SubCAs that are operated by
> > "Managed CAs", with the eventual end state being a move from the existing
> > Symantec PKI to a modernized platform. We are providing this update to
> > share our initial findings of our efforts to implement the SubCA
> proposal,
> > and as previously posted, propose aggressive but achievable dates for
> > certain aspects of the SubCA proposal.
> >
> >
> >
> > Last month, we released a Request for Proposal (RFP) that covered all
> > aspects of the SubCA proposal, including key management, technical
> > integration, staffing, training, compliance, support, and the end-to-end
> > coordination of operations. This RFP was sent to the CAs that we felt
> best
> > met the browser requirements and had the potential to successfully
> fulfill
> > the scope and volume of our CA authentication and issuance activities.
> >
> >
> >
> > After receiving RFP responses, we met with the prospective Managed CAs
> > to discuss and refine their proposed approach, clarify intent and answer
> > questions impacting their proposals, which addressed their approach to
> > and schedule for integration, staffing, compliance, support, and other
> > operational aspects.  Over the last two weeks, we have continued to
> receive
> > detailed responses from RFP respondents and hold meetings with the
> > prospective Managed CAs to review their proposals in order to select the
> > final Managed CA partner(s) that will be able to best execute on the plan
> > proposed by Google and Mozilla. We appreciate the CAs who have replied
> > and recognize that drafting the proposals required a tremendous amount
> > of time and effort as part of this accelerated process.
> >
> >
> >
> > We continue to work through implementation details with our prospective
> > Managed CA partners, to understand the depth of analysis that has gone
> > into their development schedules and staffing plans, and to assess the
> > feasibility of those plans.  We expect to complete the selection process
> > within the next 2 weeks. After selecting the final Managed CA
> partner(s), we
> > will work aggressively towards the execution of an agreement and
> > integration plan.
> >
> >
> >
> > As we finalize the selection process, our development team is actively
> > working towards the transition.  Currently, we are shifting from design
> to
> > implementation of a common set of APIs across platforms to simplify the
> > integration with one or more Managed CAs.
> >
> >
> >
> > Based on the RFP responses, internal planning, and discussions with RFP
> > respondents to date, we are still concerned with the implementation
> > timing. Based on both our own internal scoping and the RFP responses, we
> > see a practical, aggressive transition being achievable between early-
> > December and late-February, depending on the specific Managed CA(s)

Re: Certificate with invalid dnsName issued from Baltimore intermediate

2017-07-19 Thread Rob Stradling via dev-security-policy 

On 19/07/17 15:31, Jeremy Rowley via dev-security-policy wrote:

You should also filter out expired certs as they aren't usable.


I've added a 2nd tab that just shows unexpired certs.  I'll also add a 
column to track the revocation status of each of these certs.


I've left the expired certs in the 1st tab, since they show historical 
issuance problems.  Perhaps some of those CAs still have code bugs that 
need to be fixed.



On Jul 19, 2017, at 8:30 AM, Alex Gaynor via dev-security-policy 
 wrote:

I think there might be a bug in your SQL, one of the offending certs is
issued by "C=US, O=U.S. Government, OU=Department of Homeland Security,
OU=Certification Authorities, OU=DHS CA4", who are revoked using OneCRL.

Alex

On Wed, Jul 19, 2017 at 10:08 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On 18/07/17 16:57, Hanno Böck via dev-security-policy wrote:



(Due to limitations in the search methodology - scraping crt.sh
search results and looping through tlds - I only searched for ..tld. It
would certainly be valuable to search further.)



Here's a report of all "double dot" certs known to crt.sh that are useable
for server authentication and chain to a root trusted by Mozilla:

https://docs.google.com/spreadsheets/d/18rvkdAd9A_N9_i2jIVhN
QVWODGhRtIT1iYoVms7Wb2w/edit?usp=sharing


P.S.
For anyone interested, here's the SQL I executed on the crt.sh DB to
produce this report:

SELECT c.ID, x509_notBefore(c.CERTIFICATE), x509_notAfter(c.CERTIFICATE),
array_to_string(array_agg(DISTINCT ci.NAME_VALUE), CHR(10)), ca.NAME
  FROM certificate_identity ci, ca, certificate c
  WHERE ci.NAME_VALUE LIKE '%..%'
AND ci.NAME_TYPE IN ('dNSName', 'commonName')
AND ci.ISSUER_CA_ID = ca.ID
AND ci.CERTIFICATE_ID = c.ID
AND EXISTS (
  SELECT 1
FROM ca_trust_purpose ctp
WHERE ci.ISSUER_CA_ID = ctp.CA_ID
  AND ctp.TRUST_PURPOSE_ID = 1  -- Server Authentication
  AND ctp.TRUST_CONTEXT_ID = 5  -- Mozilla
)
AND x509_isEKUPermitted(c.CERTIFICATE, '1.3.6.1.5.5.7.3.1')
  GROUP BY c.ID, x509_notBefore(c.CERTIFICATE),
x509_notAfter(c.CERTIFICATE), ci.NAME_VALUE, ca.NAME
  ORDER BY ca.NAME, x509_notAfter(c.CERTIFICATE) DESC;


--
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 with invalid dnsName issued from Baltimore intermediate

2017-07-19 Thread Rob Stradling via dev-security-policy 
Hi Alex.  This is about issuance (mal)practices, so therefore I didn't 
omit certs that are already revoked.


On 19/07/17 15:29, Alex Gaynor via dev-security-policy wrote:

I think there might be a bug in your SQL, one of the offending certs is
issued by "C=US, O=U.S. Government, OU=Department of Homeland Security,
OU=Certification Authorities, OU=DHS CA4", who are revoked using OneCRL.

Alex

On Wed, Jul 19, 2017 at 10:08 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On 18/07/17 16:57, Hanno Böck via dev-security-policy wrote:



(Due to limitations in the search methodology - scraping crt.sh
search results and looping through tlds - I only searched for ..tld. It
would certainly be valuable to search further.)



Here's a report of all "double dot" certs known to crt.sh that are useable
for server authentication and chain to a root trusted by Mozilla:

https://docs.google.com/spreadsheets/d/18rvkdAd9A_N9_i2jIVhN
QVWODGhRtIT1iYoVms7Wb2w/edit?usp=sharing


P.S.
For anyone interested, here's the SQL I executed on the crt.sh DB to
produce this report:

SELECT c.ID, x509_notBefore(c.CERTIFICATE), x509_notAfter(c.CERTIFICATE),
array_to_string(array_agg(DISTINCT ci.NAME_VALUE), CHR(10)), ca.NAME
   FROM certificate_identity ci, ca, certificate c
   WHERE ci.NAME_VALUE LIKE '%..%'
 AND ci.NAME_TYPE IN ('dNSName', 'commonName')
 AND ci.ISSUER_CA_ID = ca.ID
 AND ci.CERTIFICATE_ID = c.ID
 AND EXISTS (
   SELECT 1
 FROM ca_trust_purpose ctp
 WHERE ci.ISSUER_CA_ID = ctp.CA_ID
   AND ctp.TRUST_PURPOSE_ID = 1  -- Server Authentication
   AND ctp.TRUST_CONTEXT_ID = 5  -- Mozilla
 )
 AND x509_isEKUPermitted(c.CERTIFICATE, '1.3.6.1.5.5.7.3.1')
   GROUP BY c.ID, x509_notBefore(c.CERTIFICATE),
x509_notAfter(c.CERTIFICATE), ci.NAME_VALUE, ca.NAME
   ORDER BY ca.NAME, x509_notAfter(c.CERTIFICATE) DESC;

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


--
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 with invalid dnsName issued from Baltimore intermediate

2017-07-19 Thread Jeremy Rowley via dev-security-policy 
You should also filter out expired certs as they aren't usable.

> On Jul 19, 2017, at 8:30 AM, Alex Gaynor via dev-security-policy 
>  wrote:
> 
> I think there might be a bug in your SQL, one of the offending certs is
> issued by "C=US, O=U.S. Government, OU=Department of Homeland Security,
> OU=Certification Authorities, OU=DHS CA4", who are revoked using OneCRL.
> 
> Alex
> 
> On Wed, Jul 19, 2017 at 10:08 AM, Rob Stradling via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> On 18/07/17 16:57, Hanno Böck via dev-security-policy wrote:
>> 
>> 
>>> (Due to limitations in the search methodology - scraping crt.sh
>>> search results and looping through tlds - I only searched for ..tld. It
>>> would certainly be valuable to search further.)
>>> 
>> 
>> Here's a report of all "double dot" certs known to crt.sh that are useable
>> for server authentication and chain to a root trusted by Mozilla:
>> 
>> https://docs.google.com/spreadsheets/d/18rvkdAd9A_N9_i2jIVhN
>> QVWODGhRtIT1iYoVms7Wb2w/edit?usp=sharing
>> 
>> 
>> P.S.
>> For anyone interested, here's the SQL I executed on the crt.sh DB to
>> produce this report:
>> 
>> SELECT c.ID, x509_notBefore(c.CERTIFICATE), x509_notAfter(c.CERTIFICATE),
>> array_to_string(array_agg(DISTINCT ci.NAME_VALUE), CHR(10)), ca.NAME
>>  FROM certificate_identity ci, ca, certificate c
>>  WHERE ci.NAME_VALUE LIKE '%..%'
>>AND ci.NAME_TYPE IN ('dNSName', 'commonName')
>>AND ci.ISSUER_CA_ID = ca.ID
>>AND ci.CERTIFICATE_ID = c.ID
>>AND EXISTS (
>>  SELECT 1
>>FROM ca_trust_purpose ctp
>>WHERE ci.ISSUER_CA_ID = ctp.CA_ID
>>  AND ctp.TRUST_PURPOSE_ID = 1  -- Server Authentication
>>  AND ctp.TRUST_CONTEXT_ID = 5  -- Mozilla
>>)
>>AND x509_isEKUPermitted(c.CERTIFICATE, '1.3.6.1.5.5.7.3.1')
>>  GROUP BY c.ID, x509_notBefore(c.CERTIFICATE),
>> x509_notAfter(c.CERTIFICATE), ci.NAME_VALUE, ca.NAME
>>  ORDER BY ca.NAME, x509_notAfter(c.CERTIFICATE) DESC;
>> 
>> --
>> 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
>> 
> ___
> 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

Re: Certificate with invalid dnsName issued from Baltimore intermediate

2017-07-19 Thread Alex Gaynor via dev-security-policy 
I think there might be a bug in your SQL, one of the offending certs is
issued by "C=US, O=U.S. Government, OU=Department of Homeland Security,
OU=Certification Authorities, OU=DHS CA4", who are revoked using OneCRL.

Alex

On Wed, Jul 19, 2017 at 10:08 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 18/07/17 16:57, Hanno Böck via dev-security-policy wrote:
> 
>
>> (Due to limitations in the search methodology - scraping crt.sh
>> search results and looping through tlds - I only searched for ..tld. It
>> would certainly be valuable to search further.)
>>
>
> Here's a report of all "double dot" certs known to crt.sh that are useable
> for server authentication and chain to a root trusted by Mozilla:
>
> https://docs.google.com/spreadsheets/d/18rvkdAd9A_N9_i2jIVhN
> QVWODGhRtIT1iYoVms7Wb2w/edit?usp=sharing
>
>
> P.S.
> For anyone interested, here's the SQL I executed on the crt.sh DB to
> produce this report:
>
> SELECT c.ID, x509_notBefore(c.CERTIFICATE), x509_notAfter(c.CERTIFICATE),
> array_to_string(array_agg(DISTINCT ci.NAME_VALUE), CHR(10)), ca.NAME
>   FROM certificate_identity ci, ca, certificate c
>   WHERE ci.NAME_VALUE LIKE '%..%'
> AND ci.NAME_TYPE IN ('dNSName', 'commonName')
> AND ci.ISSUER_CA_ID = ca.ID
> AND ci.CERTIFICATE_ID = c.ID
> AND EXISTS (
>   SELECT 1
> FROM ca_trust_purpose ctp
> WHERE ci.ISSUER_CA_ID = ctp.CA_ID
>   AND ctp.TRUST_PURPOSE_ID = 1  -- Server Authentication
>   AND ctp.TRUST_CONTEXT_ID = 5  -- Mozilla
> )
> AND x509_isEKUPermitted(c.CERTIFICATE, '1.3.6.1.5.5.7.3.1')
>   GROUP BY c.ID, x509_notBefore(c.CERTIFICATE),
> x509_notAfter(c.CERTIFICATE), ci.NAME_VALUE, ca.NAME
>   ORDER BY ca.NAME, x509_notAfter(c.CERTIFICATE) DESC;
>
> --
> 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
>
___
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

2017-07-19 Thread Peter Gutmann via dev-security-policy 
Hanno Böck via dev-security-policy  
writes:

>More dotdot-certificates:

Given how widespread (meaning from different CAs) these are, is there some
quirk of a widely-used resolver library that allows them?  I've done a bit of
impromptu testing of various tools/bits of code but none of them seem to allow
double-dot domain names, so I'm wondering why there's so many of them that no-
one's ever caught, until now by explicitly searching for them.

Peter.
___
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

2017-07-19 Thread Rob Stradling via dev-security-policy 

On 18/07/17 16:57, Hanno Böck via dev-security-policy wrote:


(Due to limitations in the search methodology - scraping crt.sh
search results and looping through tlds - I only searched for ..tld. It
would certainly be valuable to search further.)


Here's a report of all "double dot" certs known to crt.sh that are 
useable for server authentication and chain to a root trusted by Mozilla:


https://docs.google.com/spreadsheets/d/18rvkdAd9A_N9_i2jIVhNQVWODGhRtIT1iYoVms7Wb2w/edit?usp=sharing


P.S.
For anyone interested, here's the SQL I executed on the crt.sh DB to 
produce this report:


SELECT c.ID, x509_notBefore(c.CERTIFICATE), 
x509_notAfter(c.CERTIFICATE), array_to_string(array_agg(DISTINCT 
ci.NAME_VALUE), CHR(10)), ca.NAME

  FROM certificate_identity ci, ca, certificate c
  WHERE ci.NAME_VALUE LIKE '%..%'
AND ci.NAME_TYPE IN ('dNSName', 'commonName')
AND ci.ISSUER_CA_ID = ca.ID
AND ci.CERTIFICATE_ID = c.ID
AND EXISTS (
  SELECT 1
FROM ca_trust_purpose ctp
WHERE ci.ISSUER_CA_ID = ctp.CA_ID
  AND ctp.TRUST_PURPOSE_ID = 1  -- Server Authentication
  AND ctp.TRUST_CONTEXT_ID = 5  -- Mozilla
)
AND x509_isEKUPermitted(c.CERTIFICATE, '1.3.6.1.5.5.7.3.1')
  GROUP BY c.ID, x509_notBefore(c.CERTIFICATE), 
x509_notAfter(c.CERTIFICATE), ci.NAME_VALUE, ca.NAME

  ORDER BY ca.NAME, x509_notAfter(c.CERTIFICATE) DESC;

--
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

Miss-issuance: URI in dNSName SAN

2017-07-19 Thread Alex Gaynor via dev-security-policy 
Morning all,

I'd like to report the following instance of miss-issuance:

All of the following contain a URI in a dNSName SAN entry. These
certificates are neither revoked, nor expired, and all are from CAs
currently trusted by the Mozilla Root Program.

https://crt.sh/?id=124094761=cablint
Issuer: 
commonName= PSCProcert
countryName   = VE
organizationName  = Sistema Nacional de
Certificacion Electronica
organizationalUnitName= Proveedor de Certificados PROCERT
stateOrProvinceName   = Miranda
localityName  = Chacao
emailAddress  = conta...@procert.net.ve

https://crt.sh/?id=42531587=cablint
Issuer: 
commonName= Camerfirma AAPP II - 2014
localityName  = Madrid (see current address at
https://www.camerfirma.com/address)
serialNumber  = A82743287
organizationName  = AC Camerfirma S.A.
organizationalUnitName= AC CAMERFIRMA
countryName   = ES

https://crt.sh/?id=5129200=cablint
Issuer: 
commonName= AC CAMERFIRMA AAPP
serialNumber  = A82743287
organizationalUnitName= AC CAMERFIRMA
localityName  = MADRID (Ver en
https://www.camerfirma.com/address)
organizationName  = AC CAMERFIRMA S.A.
countryName   = ES



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

Re: TunRootCA2 root inclusion request

2017-07-19 Thread Charles Reiss via dev-security-policy 

On 07/19/17 05:10, Aaron Wu wrote:

- Tunisian Server Certificate Authority - TunServerCA2



https://crt.sh/?id=21813439 is a certificate issued by this CA which has 
a domain name in the common name but only an email address in the SAN. 
(The certificate has TLS server/client usage EKUs.)



https://crt.sh/?id=99182607 is a revoked certificate issued by this CA 
which has a domain name in the common name which does not match the 
domain name in the SAN, which is for a different TLD. (A new certificate 
with both names in SANs, https://crt.sh/?id=99462700 , has a notBefore 
which appears to have around the same timestamp as the revocation.)



https://crt.sh/?id=15126121 is an expired certificate (notBefore March 
2016; notAfter March 2017) issued by this CA which has a wildcard name 
in the common name while the SAN contains specific domain names that 
would be covered by the wildcard only.



https://crt.sh/?id=10975511 is an expired certificate with a notBefore 
of Oct 2015 and notAfter of Oct 2016 issued by this CA with an iPAddress 
SAN of 127.0.0.1. (I believe that by 2014, the BRs prohibited issuing 
internal name certs with validity past November 2015.)

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

TunRootCA2 root inclusion request

2017-07-19 Thread Aaron Wu via dev-security-policy 
This request from the Government of Tunisia is to include the “Tunisian Root 
Certificate Authority - TunRootCA2” root certificate, and enable the Websites 
trust bit.

The request is documented in the following bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1233645

BR Self Assessment is here:
https://bugzilla.mozilla.org/attachment.cgi?id=8865381

Summary of Information Gathered and Verified: 
https://bugzilla.mozilla.org/attachment.cgi?id=8884764

* Root Certificate Download URL: 
http://www.certification.tn/pub/TunRootCA2.crt

* Documents are in French, translated in English
CP/CPS in French: 
http://www.certification.tn/sites/default/files/documents/PolitiqueSERVEURS-PTC-BR-05.pdf

CP/CPS in English: 
http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-05.pdf


* CA Hierarchy: 
This root will have internally-operated subordinate CAs. 
Currently it has one internally-operated subordinate CA:
- Tunisian Server Certificate Authority - TunServerCA2

* This request is to turn on the Websites trust bit. EV treatment is not 
requested.

* CP/CPS of the Tunisian Server Certificate Authority PTC BR:

** Section 1.3.4: 
“In the context of this CP / CPS, a Server Certificate Responsible (SCR) is a 
natural person who is responsible for using the certificate of the server or 
computer device identified in the certificate and the private key corresponding 
to this certificate, on behalf of the entity identified in that certificate. 
The SCR is contractually, hierarchically or legally bound to this entity.”

** Section 3.2.2:
“Authentication of a client organization is done by checking the following 
documents:
The certificate application form duly completed and signed by the applicant, 
acting as a certificate request, containing in particular the postal address, 
the professional e-mail address and the telephone number enabling the NDCA to 
contact the future bearer;
• A copy of the National Identity Card, passport or residence card of the 
applicant and the SCR;
• An extract from the trade register not exceeding three months;
The bearer must be informed that the personal identity information he has 
provided for the registration file will be retained.
The verification and validation of the request are carried out in accordance 
with the provisions described in section 4.2.”

** Section 4.2.1:
"For the purpose of verifying the identities of the applicants, the RA, 
performs the following operations:
check the consistency of the registration dossier and the supporting documents 
submitted;
verify the accuracy of the purchase order and payment;
verify that the organization holds the domain name by consulting the official 
databases of AFRINIC or INTERNIC domain names, and 
ensure that the SCR is aware of the terms and conditions applicable to the use 
of the certificate.
Upon completion of these transactions, the RA sends the request to the CA 
components responsible for certificate production. The RA then retains a copy 
of the proof of identity submitted in paper or electronic form having a legal 
value.”


* EV Policy OID: Not Requesting EV treatment 

* Test Websites
Valid certificate: https://valid-ov.certification.tn
Revoked certificate: https://revoked-ov.certification.tn
Expired certificate: https://expired-ov.certification.tn

* CRL URLs: 
http://crl.certification.tn/TunRootCA2.crl
http://crl.certification.tn/TunServerCA2.crl 
CP/CPS section 2.3: A new CRL is published every 24 hours

* OCSP URLs:
http://ocsp.certification.tn
OCSP responses have a maximum expiration time of 10 days.

* Audit: Annual audits are performed by LSTI according to the ETSI TS 102 042 
for CA and BR audit criteria.
https://bug1233645.bmoattachments.org/attachment.cgi?id=8879910


* Forbidden or Problematic Practices 
(https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices)
None Noted

This begins the discussion of the request from the Government of Tunisia is to 
include the “Tunisian Root Certificate Authority - TunRootCA2” root 
certificate, and enable the Websites trust bit.

I will greatly appreciate your constructive and thoughtful feedback on this 
request.

Aaron
___
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

2017-07-19 Thread Nick Lamb via dev-security-policy 
On Tuesday, 18 July 2017 20:29:50 UTC+1, Jeremy Rowley  wrote:
> Some of these certs are really old.  Is there a reason people were using 
> double dot names? Are they all mistakes in the certificate request or is 
> there some logic behind them?

Unless I see good evidence to the contrary I will assume mistakes. The 
personnel with responsibility for obtaining certificates in most organisations 
know very little about this stuff. If you offer them a box where they can type 
www. and it doesn't say "Bzzt, wrong! Try again" they will only find out that 
the resulting certificates are garbage when they try them.

Anecdote: My employer uses a popular brand of SSL-intercepting Middle Box, and 
they had used its "demo" root CA for months or possibly years before I pointed 
out that this was a grave security risk detailed in the product's own manual. 
No-one would officially acknowledge my warning, but after a few months it 
evidently reached someone with the power to change things, and so one morning 
the CA was silently replaced and a new CA root cert was pushed out to all the 
Windows clients. This new "root cert" lacked CA:TRUE and had clearly been 
created by typing whatever seemed intuitively reasonable into all the X.500 
series name fields. Certificates presented to end user machines by the Middle 
Box were now signed by this "CA".

Interestingly this was accepted by Windows as a root cert. But not by lots of 
other systems due to lack of CA:TRUE, and within two days the root was replaced 
once again, this time using a cert that looked exactly like the one for the 
original demo CA, including CA:TRUE, and all the name branding from the 
supplier but with a different key pair. Since this CA was not obviously unsafe, 
I held my tongue about the other problems with it and counted it as a win for 
security.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy