Please put also this certificate on that list:
https://crt.sh/?id=181538497&opt=cablint,x509lint
Best Regards,
Jozsef
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
On Thu, Mar 15, 2018 at 12:22 PM, Tom via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Should another bug be opened for the certificate issued by IdenTrust with
> apparently the same encoding problem?
>
> Yes - this is bug 1446121 (
https://bugzilla.mozilla.org/show_bug.cg
Le 15/03/2018 à 20:04, Wayne Thayer a écrit :
This incident, and the resulting action to "integrate GlobalSign's certlint
and/or zlint into our existing cert-checker pipeline" has been documented
in bug 1446080 [1]
This is further proof that pre-issuance TBS certificate linting (either by
incorp
This incident, and the resulting action to "integrate GlobalSign's certlint
and/or zlint into our existing cert-checker pipeline" has been documented
in bug 1446080 [1]
This is further proof that pre-issuance TBS certificate linting (either by
incorporating existing tools or using a comprehensive
On Tuesday, March 13, 2018 at 4:27:23 PM UTC-6, Matthew Hardeman wrote:
> I thought I recalled a recent case in which a new root/key was declined
> with the sole unresolved (and unresolvable, save for new key generation,
> etc.) matter precluding the inclusion being a prior mis-issuance of test
> c
On Tue, Mar 13, 2018 at 6:27 PM Matthew Hardeman
wrote:
> Another question this incident raised in my mind pertains to the parallel
>>> staging and production environment paradigm: If one truly has the
>>> 'courage
>>> of conviction' of the equivalence of the two environments, why would one
>>>
> So to clarify I understand this: The same problem was in the staging
> environment and there where also certificates with illegal encoding issued in
> staging, but you didn't notice them because no one manually validated them
> with the crt.sh lint?
That's correct.
> Or are there difference
On Tuesday, March 13, 2018 at 23:51:01 UTC+1 js...@letsencrypt.org wrote:
> Clearly we should have caught this earlier in the process. The changes we
> have in the pipeline (integrating certlint and/or zlint) would have
> automatically caught the encoding issue at each staging in the pipeline: i
On Tuesday, March 13, 2018 at 2:02:45 PM UTC-7, Ryan Sleevi wrote:
> I'm hoping that LE can provide more details about the change management
> process and how, in light of this incident, it may change - both in terms
> of automated testing and in certificate policy review.
Forgot to reply to this
On Tue, Mar 13, 2018 at 4:02 PM, Ryan Sleevi wrote:
>
>
> On Tue, Mar 13, 2018 at 4:13 PM, Matthew Hardeman via dev-security-policy
> wrote:
>
>> I am not at all suggesting consequences for Let's Encrypt, but rather
>> raising a question as to whether that position on new inclusions /
>> renewal
On Tuesday, March 13, 2018 at 2:02:45 PM UTC-7, Ryan Sleevi wrote:
> availability of certificate linting tools - such as ZLint, x509Lint,
> (AWS's) certlint, and (GlobalSign's) certlint - there's no dearth of
> availability of open tools and checks. Given the industry push towards
> integration of
On Tue, Mar 13, 2018 at 4:13 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I am not at all suggesting consequences for Let's Encrypt, but rather
> raising a question as to whether that position on new inclusions / renewals
> is appropriate. If thes
The fact that this mis-issuance occurred does raise a question for the
community.
For quite some time, it has been repeatedly emphasized that maintaining a
non-trusted but otherwise identical staging environment and practicing all
permutations of tests and issuances -- especially involving new
fun
On Tuesday, March 13, 2018 at 3:33:50 AM UTC-5, Tom wrote:
> > During final tests for the general availability of wildcard
> certificate support, the Let's Encrypt operations team issued six test
> wildcard certificates under our publicly trusted root:
> >
> > https://crt.sh/?id=353759994
> >
> During final tests for the general availability of wildcard
certificate support, the Let's Encrypt operations team issued six test
wildcard certificates under our publicly trusted root:
>
> https://crt.sh/?id=353759994
> https://crt.sh/?id=353758875
> https://crt.sh/?id=353757861
> https://crt
On Mon, Mar 12, 2018 at 11:38 PM jacob.hoffmanandrews--- via
dev-security-policy wrote:
> On Monday, March 12, 2018 at 8:22:46 PM UTC-7, Ryan Sleevi wrote:
> > Given that Let's Encrypt has been operating a Staging Endpoint (
> > https://letsencrypt.org/docs/staging-environment/ ) for issuing
> wi
On Monday, March 12, 2018 at 8:27:06 PM UTC-7, Ryan Sleevi wrote:
> Also, is this the correct timestamp? For example, examining
> https://crt.sh/?id=353754255&opt=ocsp
>
> Shows an issuance time of Not Before: Mar 12 22:18:30 2018 GMT and a
> revocation time of 2018-03-12 23:58:10 UTC , but you s
On Monday, March 12, 2018 at 8:22:46 PM UTC-7, Ryan Sleevi wrote:
> Given that Let's Encrypt has been operating a Staging Endpoint (
> https://letsencrypt.org/docs/staging-environment/ ) for issuing wildcards,
> what controls, if any, existed to examine the certificate profiles prior to
> being dep
On Mon, Mar 12, 2018 at 11:22 PM, Ryan Sleevi wrote:
>
>
> On Mon, Mar 12, 2018 at 10:35 PM, josh--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> During final tests for the general availability of wildcard certificate
>> support, the Let's Encrypt operations team
On Mon, Mar 12, 2018 at 10:35 PM, josh--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> During final tests for the general availability of wildcard certificate
> support, the Let's Encrypt operations team issued six test wildcard
> certificates under our publicly truste
20 matches
Mail list logo