Re: Misissued/Suspicious Symantec Certificates

2017-03-01 Thread Martin Heaps via dev-security-policy 
On Tuesday, 28 February 2017 17:45:19 UTC, Santhan Raj  wrote:

> WebTrust  for Certification   Authorities ,   SSL 
> BaselinewithNetwork Security,   Version 2.0,available 
>   at
> http://www.webtrust.org/homepage‐documents/item79806.pdf.

404 - File or directory not found.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)

2017-03-01 Thread douglas.beattie--- via dev-security-policy 
On Wednesday, March 1, 2017 at 8:26:34 AM UTC-5, Peter Kurrasch wrote:
> Would it be possible to get a more precise answer other than "in accordance 
> with"? I am left to assume that in fact no verification was performed because 
> the previous verification was in the 39 month window.

For this SSL product, customers place orders which are vetted to the OV level 
with normally just a single SAN.  Once the order has been approved they can add 
SANs by verifying domain control via DNS or File based verificaton options.  
Over time they add and remove SANs as their customer base changes.  They can 
re-issue the certificate which keeps the expiration date and the subject DN the 
same, but they add and remove SANs.

In this case they did not remove SAN which are clearly not functional and are 
for domains which have expired. The reissueance process does not require the 
re-verification of the domain control, thus the certificate was reissued with 
these SANs.

Subscribers are required to tell us when the certificate contents is no-longer 
accurate so appropriate action can be taken, but clearly this customer did not 
inform us.  We'll be talking with them about this to find out why.

Doug
> 
>   Original Message  
> From: douglas.beattie--- via dev-security-policy
> Sent: Tuesday, February 28, 2017 6:46 AM‎
> 
> ...snip...
> ‎
> > I also would like to have an official reply from GlobalSign saying that "on 
> > the date they issue the certificate the domain exists".
> 
> On the date that the certificate was issued it was verified in accordance 
> with the Domain Verification requirements in the BRs.
> 
> Doug Beattie
> GlobalSign
> ___
> 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: Intermediates Supporting Many EE Certs

2017-03-01 Thread Jakob Bohm via dev-security-policy 

On 01/03/2017 12:43, Gervase Markham wrote:

On 13/02/17 12:23, Gervase Markham wrote:

The GoDaddy situation raises an additional issue.



What can be done about the potential future issue (which might happen
with any large CA) of the need to untrust a popular intermediate?
Suggestions welcome.


Reviewing the discussion, I unfortunately don't see any workable
solutions proposed yet. I think AIA chasing is a red herring. Jeremy's
engagement on intermediate rotation was illuminating, but it seems to me
that having multiple intermediates in play at the same time over an
extended period is very likely not to solve the problem, because any
issuance problem would cut across them all.

If customers tend to renew annually, one could imagine a "January
intermediate", "February intermediate" and so on, and one uses the
former every January, etc. This might reduce the need for an
intermediate change when an EE cert changes, as


CA's tend to encourage ahead-of-time annual renewals, offering to add
the leftover days to the validitiy period of the replacement
certificate (this is presumably also the reason BR max validity periods
are slightly more than a whole number of years, for example a 3 year
certificate renewed 2½ month ahead of expiry would have a validity of
38.5 months, which is less than 39).


I have sympathy for the
view that in today's world changing intermediate does make the process a
little more error prone. (Although it shouldn't, and that's a technology
fail I hope can be addressed.) Then, if you have an issuance problem
which persisted for a month but which has led to a situation where you
can't trust anything off the intermediates used during those times, only
1/6th of your outstanding certs from that root are at risk of needing
immediate change rather than all of them.


I would say a lot could be improved if certificate issuance customer
messages provided the *relevant* chains and their individual
certificates directly and with human-friendly names, it would greatly
reduce the confusion compared to the common practice of asking each EE
to manually navigate disorganized support pages for individual
certificates with semi-numerical names such as "Foo intermediate G3"

For example the confirmation mail or individualized web page could
be something like this:

--- Begin example for an OV SSL cert validated by the Joe's certs RA ---
Here is your new SSL/TLS certificate for www.example.com, example.com
and static.example.com (serial number
1231231421432453255268924750932758934750): example_com_2017_03_17.cer
(PEM format).

Needed intermediary certificates to put on your server:

All in one file (including your certificate):
example_com_2017_03_17_with_chain.pem (PEM format as needed by most
servers) Or example_com_2017_03_17_with_chain.p7 (PKCS#7 for Microsoft
IIS, Exchange etc.)

One at a time (These are included in the all-in-one files above except
the ones marked with an X, which your server shouldn't send)

  NiceCA-via-JoeRA-SSL-Regular-March-2017.cer (PEM format)

X NiceCA-SHA256RSA-Root-2016.cer (PEM format)

  NiceCA-SHA256RSA-Root-2016-cross-by-UserFirst.cer (PEM format)

X UserFirst-ancient-root.cer (PEM format)

--- End example ---



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: SHA1 root CA

2017-03-01 Thread Gervase Markham via dev-security-policy 
On 01/03/17 10:36, benjaminp...@gmail.com wrote:
> screenshot of the error message: http://imgur.com/a/BIQUm

That error message will not occur if only the root CA is SHA-1 signed,
because Firefox does not check the signatures on root CAs. There must be
some other certificate in the chain that Firefox has built which is
SHA-1 signed.

You will need to provide the full certificate chain as constructed by
Firefox. If you get the error by visiting the site, then click
"Advanced" then "Add Exception" then "View" then the "Details" tab, then
select all the certificates in the chain in turn and click Export,
making sure you save them as PEM files, you can paste them into a
message to this group.

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

Re: Let's Encrypt appears to issue a certificate for a domain thatdoesn't exist

2017-03-01 Thread Peter Kurrasch via dev-security-policy 
What you've stumbled into is the unspoken truth that CA's want to have their 
cake and eat it too.

Specifically, they market themselves and their products under the umbrella of 
security: "You want to be secure on the Internet, right? We can help you do 
that!"‎ Then, most all CA's will turn around and say: "Oh by the way, if you 
encounter a situation in which something bad happens it's not our fault because 
we couldn't possibly ‎confirm that what we say is secure is in fact secure."

Let's Encrypt is not unique as I think most CA's express this viewpoint in one 
form or another. This may be acceptable from a legal or compliance standpoint 
but not in terms of reputation. As people find themselves in bad situations 
because of a malicious site that used one of their certs, they very well might 
blame the CA.

Certainly a CA does not want the reputation of being "the preferred cert vendor 
for malicious sites everywhere" so whatever principles they try to espouse, the 
reality will be more complicated.


  Original Message  
From: wuyi via dev-security-policy
Sent: Friday, February 24, 2017 1:57 AM
To: vtlynch; dev-security-policy
Reply To: wuyi
Subject: Re: Let's Encrypt appears to issue a certificate for a domain 
thatdoesn't exist

Exactly that’s the meaning of “entitle”.
Based on the interpretation, I understand that when a firefighter is on a 
vocation, even a fire breaks next to him, it’s of his choice to go hiking, fly 
kites whatever as he may only be entitled on weekdays rather than in a 
vocation. 
IMO, the point of the Let’s Encrypt’ CP 9.6.3 is to ensure that the CA has 
privilege to revoke certificate when certain issue happens as it describes. The 
deeper meaning of it is that it ensures the CA has ability to maintain online 
security anytime, but it’s enough. I am not going to debate here, I would 
rather go and teach my grandfather those green lock icons from some certain CA 
means anything but online security they states. 
Nio 
SZU


发自我的iPhone

-- Original --
From: Vincent Lynch via dev-security-policy 

Date: Fri,Feb 24,2017 15:10
To: dev-security-policy , wuyi 
<594346...@qq.com>
Subject: Re: Let's Encrypt appears to issue a certificate for a domain 
thatdoesn't exist



As you have quoted it, Let's Encrpyt's CPS says:

"the CA is *entitled* to revoke the certificate"

The key word is "entitled." Meaning that Let's Encrypt may revoke the
certificate if they chose, but are not required to. Therefore not revoking
the certificate is compatible with their CPS.

It's important to realize this is not an argument about what *should* be
done or what we think is right, but what *can* be done under the current
rules and regulations.

The fact is that the CAB/F BR's are so (intentionally) ambiguous about
"high risk" certificates that there is no real way meaning to that section
and no real way for a CA to violate said section.




As others have mentioned, please can we stop writing unrelated comments on
this thread. This thread is about a specific report about a DV cert being
issued to a non-existent domain. That report turned out to be false. Unless
comments are about that report, this is the wrong thread to post in.

I would also encourage anyone interested in the topic of high risk requests
and certs being issued to phishing sites to see Eric Mill's comment in this
thread. He has provided a link to past discussion on this topic, and I can
promise you that however displeasing and shocking this practice may be, it
has already been considered and debated.



On Fri, Feb 24, 2017 at 12:36 AM wuyi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> According to what I’ve known,
>
>
> “Acknowledgment and Acceptance: An acknowledgment and acceptance that the
> CA is entitled to revoke the certificate immediately if the Applicant were
> to violate the terms of the Subscriber or Terms of Use Agreement or if the
> CA discovers that the Certificate is being used to enable criminal
> activities such as phishing attacks, fraud, or the distribution of
> malware.” (Let’s Encrypt’ CP 9.6.3)
>
>
>
>
> Now that a phishing site has been detected with a valid certificate, but
> no immediate action was taken on it. I don’t think that this is what a CA,
> who states to “Support a more secure and privacy-respecting Web” is
> supposed to do.
>
>
>
>
> Quoted from Google’s Policy, “it would be no different than a firefighter
> who was not responding to fires in which people died.”
>
>
> It may be difficult to sort what types of domains are high risk, but when
> a certificate was used in this way without being revoked, it was no
> difference from the Google CP’s metaphor. As an Internet user I was
> disappointed about that, and those in the LE’ CP above can be treated as
> nonsense.
>
>
> Nio
> SZU
>
>
> On Fri, Feb 24, 2017 at 01:12:38AM +, Richard Wang via
> dev-security-policy

Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)

2017-03-01 Thread Peter Kurrasch via dev-security-policy 
Would it be possible to get a more precise answer other than "in accordance 
with"? I am left to assume that in fact no verification was performed because 
the previous verification was in the 39 month window.


  Original Message  
From: douglas.beattie--- via dev-security-policy
Sent: Tuesday, February 28, 2017 6:46 AM‎

...snip...
‎
> I also would like to have an official reply from GlobalSign saying that "on 
> the date they issue the certificate the domain exists".

On the date that the certificate was issued it was verified in accordance with 
the Domain Verification requirements in the BRs.

Doug Beattie
GlobalSign
___
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: Intermediates Supporting Many EE Certs

2017-03-01 Thread okaphone.elektronika--- via dev-security-policy 
On Wednesday, 1 March 2017 12:44:16 UTC+1, Gervase Markham  wrote:
> On 13/02/17 12:23, Gervase Markham wrote:
> > The GoDaddy situation raises an additional issue.
> 
> > What can be done about the potential future issue (which might happen
> > with any large CA) of the need to untrust a popular intermediate?
> > Suggestions welcome.
> ...
> If customers tend to renew annually, one could imagine a "January
> intermediate", "February intermediate" and so on, and one uses the
> former every January, etc.
> ...

Or a different intermediate each day? ;-)

I guess what you really are looking for is being able to distrust a CA for a 
date range. Any requirement that doesn't produce that is probably not worth the 
effort.

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

Re: Intermediates Supporting Many EE Certs

2017-03-01 Thread Gervase Markham via dev-security-policy 
On 13/02/17 12:23, Gervase Markham wrote:
> The GoDaddy situation raises an additional issue.

> What can be done about the potential future issue (which might happen
> with any large CA) of the need to untrust a popular intermediate?
> Suggestions welcome.

Reviewing the discussion, I unfortunately don't see any workable
solutions proposed yet. I think AIA chasing is a red herring. Jeremy's
engagement on intermediate rotation was illuminating, but it seems to me
that having multiple intermediates in play at the same time over an
extended period is very likely not to solve the problem, because any
issuance problem would cut across them all.

If customers tend to renew annually, one could imagine a "January
intermediate", "February intermediate" and so on, and one uses the
former every January, etc. This might reduce the need for an
intermediate change when an EE cert changes, as I have sympathy for the
view that in today's world changing intermediate does make the process a
little more error prone. (Although it shouldn't, and that's a technology
fail I hope can be addressed.) Then, if you have an issuance problem
which persisted for a month but which has led to a situation where you
can't trust anything off the intermediates used during those times, only
1/6th of your outstanding certs from that root are at risk of needing
immediate change rather than all of them.

I guess the question is: is it worth it? Are the chances of this proving
useful in an actual scenario high enough compared to the cost and hassle
of imposing such a scheme on all CAs? If we decide to dis-trust the
intermediate under such a scheme, is the CA practically as stuffed as it
would be if it had just used one intermediate? :-)

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

Re: SHA1 root CA

2017-03-01 Thread Hanno Böck via dev-security-policy 
On Wed, 1 Mar 2017 02:36:22 -0800 (PST)
benjaminpill--- via dev-security-policy
 wrote:

> when connecting to a webserver
> 
> screenshot of the error message: http://imgur.com/a/BIQUm

It would be helpful if you told us which webserver. The error message
looks to me that it's web webpages certificate, not the root, that's
signed with sha1. But I may be wrong, would have to check.
Sometimes error messages are misleading and sometimes strange things
happen when websites send all kinds of wrong certs within a chain.

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

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SHA1 root CA

2017-03-01 Thread Pascal Ernster via dev-security-policy 
[2017-03-01 11:21] benjaminpill--- via dev-security-policy:
> so why is Firefox complaining with this error message:
> 
> SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED


Check the about:config setting "security.pki.sha1_enforcement_level".
Valid values currently range from 0 to 4, with the following meanings:

>   enum class SHA1Mode {
> Allowed = 0,
> Forbidden = 1,
> // There used to be a policy that only allowed SHA1 for certificates 
> issued
> // before 2016. This is no longer available. If a user has selected this
> // policy in about:config, it now maps to Forbidden.
> UsedToBeBefore2016ButNowIsForbidden = 2,
> ImportedRoot = 3,
> ImportedRootOrBefore2016 = 4,
>   };

Source:
https://dxr.mozilla.org/mozilla-central/source/security/certverifier/CertVerifier.h#164

You'll probably want either value 3 or value 4.


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

Re: SHA1 root CA

2017-03-01 Thread benjaminpill--- via dev-security-policy 
Am Mittwoch, 1. März 2017 11:31:20 UTC+1 schrieb Hanno Böck:
> On Wed, 1 Mar 2017 02:21:21 -0800 (PST)
> benjaminpill--- via dev-security-policy
>  wrote:
> 
> > so why is Firefox complaining with this error message:
> > 
> > SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED
> 
> Can you be more specific? Where are you seeing that error message?
> 
> -- 
> Hanno Böck
> https://hboeck.de/
> 
> mail/jabber: ha...@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

when connecting to a webserver

screenshot of the error message: http://imgur.com/a/BIQUm
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SHA1 root CA

2017-03-01 Thread Hanno Böck via dev-security-policy 
On Wed, 1 Mar 2017 02:21:21 -0800 (PST)
benjaminpill--- via dev-security-policy
 wrote:

> so why is Firefox complaining with this error message:
> 
> SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED

Can you be more specific? Where are you seeing that error message?

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

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SHA1 root CA

2017-03-01 Thread benjaminpill--- via dev-security-policy 
Am Mittwoch, 1. März 2017 11:18:48 UTC+1 schrieb Hanno Böck:
> On Wed, 1 Mar 2017 00:44:54 -0800 (PST)
> benjaminpill--- via dev-security-policy
>  wrote:
> 
> > are root (Enterprise) CA certificates wich are based on SHA1 handled
> > as untrusted by Firefox 51? The  end certificate is sign using sha256
> > and trusted by a intermidiate ca wich uses also sha256. Only the root
> > ca is based on sha1. Chrome and IE are not complaining about the root
> > cert.
> 
> The signatures on root certificates are mostly irrelevant, as they're
> pure self-signatures that have no real meaning. I think they're
> only there because the certificate format X.509 requires certificates to
> have a signature on themselve.
> 
> Therefore afaik it's generally considered okay if root certificates have
> SHA1 signatures. You probably wouldn't create new ones with such
> signatures, but there is no risk for the ecosystem in keeping existing
> ones.
> 
> -- 
> Hanno Böck
> https://hboeck.de/
> 
> mail/jabber: ha...@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

so why is Firefox complaining with this error message:

SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED

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

Re: SHA1 root CA

2017-03-01 Thread Hanno Böck via dev-security-policy 
On Wed, 1 Mar 2017 00:44:54 -0800 (PST)
benjaminpill--- via dev-security-policy
 wrote:

> are root (Enterprise) CA certificates wich are based on SHA1 handled
> as untrusted by Firefox 51? The  end certificate is sign using sha256
> and trusted by a intermidiate ca wich uses also sha256. Only the root
> ca is based on sha1. Chrome and IE are not complaining about the root
> cert.

The signatures on root certificates are mostly irrelevant, as they're
pure self-signatures that have no real meaning. I think they're
only there because the certificate format X.509 requires certificates to
have a signature on themselve.

Therefore afaik it's generally considered okay if root certificates have
SHA1 signatures. You probably wouldn't create new ones with such
signatures, but there is no risk for the ecosystem in keeping existing
ones.

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

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

SHA1 root CA

2017-03-01 Thread benjaminpill--- via dev-security-policy 
Hello,

are root (Enterprise) CA certificates wich are based on SHA1 handled as 
untrusted by Firefox 51?
The  end certificate is sign using sha256 and trusted by a intermidiate ca wich 
uses also sha256. Only the root ca is based on sha1.
Chrome and IE are not complaining about the root cert.

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