On 11/18/2014 05:44 PM, Reindl Harald wrote:
Am 18.11.2014 um 16:12 schrieb Michael Catanzaro:
On Tue, 2014-11-18 at 12:11 +0100, Florian Weimer wrote:
Firefox also builds a repository of intermediate certificates over
time
and uses them automatically to fill gaps in certificate chains for
com
Am 18.11.2014 um 16:12 schrieb Michael Catanzaro:
On Tue, 2014-11-18 at 12:11 +0100, Florian Weimer wrote:
Firefox also builds a repository of intermediate certificates over
time
and uses them automatically to fill gaps in certificate chains for
completely unrelated sites. This leads to somewh
On Tue, 2014-11-18 at 12:11 +0100, Florian Weimer wrote:
> Firefox also builds a repository of intermediate certificates over
> time
> and uses them automatically to fill gaps in certificate chains for
> completely unrelated sites. This leads to somewhat non-predictable
> behavior regarding the
On 09/08/2014 04:00 PM, Michael Catanzaro wrote:
This is a very big problem for the GNOME stack, which uses gnutls. We're
getting complaints about sites that Epiphany can't display because the
CSS fails certificate validation, or sites that don't display at all,
which all work fine in Firefox.
- Original Message -
> This isn't a recent change, see [1]. I presume Amazon is most likely
> still broken in Epiphany (when these roots are removed) as there's been
> no action on [1], where we decided that gnutls-cli accepted
> www.amazon.com because it uses certs if they're valid for eit
On Fri, 2014-10-31 at 16:28 +0100, Kai Engert wrote:
> I confirm that using GnuTLS 3.3.9-2.fc21 on Fedora 21 testing,
> with ca-certificates-2014.2.1-1.3.fc21,
> and ca-legacy set to disabled,
> the command
> gnutls-cli -p443 www.amazon.com
> reports a trusted certificate.
This isn't a recent c
On Fri, 2014-10-31 at 15:53 +0100, Nikos Mavrogiannopoulos wrote:
> Are you sure that this is the case with the current package? My F21
> can
> no longer connect to network to test, but gnutls in it should
> reconstruct the chain similarly to what nss does (not very similarly
> to
> be precise but
On Fri, 2014-10-31 at 16:11 +0100, Reindl Harald wrote:
> > Are you sure that this is the case with the current package? My F21 can
> > no longer connect to network to test, but gnutls in it should
> > reconstruct the chain similarly to what nss does (not very similarly to
> > be precise but the e
On Fri, 2014-10-31 at 15:00 +0100, Nikos Mavrogiannopoulos wrote:
> > Sorry for my late reply, because I didn't have a good suggestion
> > earlier.
> >
> > We should work with the upstream OpenSSL and the GnuTLS projects, and
> > motivate them to implement more advanced path building. This would b
Am 31.10.2014 um 15:53 schrieb Nikos Mavrogiannopoulos:
On Fri, 2014-10-31 at 09:49 -0500, Michael Catanzaro wrote:
We should work with the upstream OpenSSL and the GnuTLS projects,
and
motivate them to implement more advanced path building. This would
be a
long term project.
Is there some
On Fri, 2014-10-31 at 09:49 -0500, Michael Catanzaro wrote:
> > > We should work with the upstream OpenSSL and the GnuTLS projects,
> > and
> > > motivate them to implement more advanced path building. This would
> > be a
> > > long term project.
> > Is there some issue with gnutls in F21? As far a
On Fri, 2014-10-31 at 15:00 +0100, Nikos Mavrogiannopoulos wrote:
> > We should work with the upstream OpenSSL and the GnuTLS projects,
> and
> > motivate them to implement more advanced path building. This would
> be a
> > long term project.
>
> Is there some issue with gnutls in F21? As far as I
On Fri, 2014-10-31 at 14:05 +0100, Kai Engert wrote:
> On Wed, 2014-10-15 at 12:28 +0200, Vít Ondruch wrote:
> > Nevertheless, I am still unsure how to proceed with RubyGems. Should I
> > ship the bundled certificates again? Or should I wait until somebody
> > notices?
>
> Sorry for my late reply,
On Wed, 2014-10-15 at 12:28 +0200, Vít Ondruch wrote:
> Nevertheless, I am still unsure how to proceed with RubyGems. Should I
> ship the bundled certificates again? Or should I wait until somebody
> notices?
Sorry for my late reply, because I didn't have a good suggestion
earlier.
We should work
Dne 17.9.2014 v 14:05 Kai Engert napsal(a):
> On Mon, 2014-09-08 at 12:53 +0200, Vít Ondruch wrote:
>>> I believe that we must contact Amazon and Symantec about this issue.
>>> Amazon should remove the second intermediate, ending the path with the
>>> G5 intermediate. This will allow openssl to fin
On Wed, 2014-09-17 at 14:16 +0200, Kai Engert wrote:
> I think it's good that we have started experimenting with these
> removals
> in the testing areas of Fedora, because it raises awareness of these
> issues, and hopefully can bring higher priority to getting OpenSSL and
> GnuTLS enhanced.
>
> B
On Mon, 2014-09-08 at 09:00 -0500, Michael Catanzaro wrote:
> On Mon, 2014-09-08 at 10:06 +0200, Nikos Mavrogiannopoulos wrote:
> > Unfortunately only NSS works. Both openssl and gnutls fail to connect to
> > popular sites because of that change. It should not be assumed that the
> > users of ca-ce
On Mon, 2014-09-08 at 12:53 +0200, Vít Ondruch wrote:
> > I believe that we must contact Amazon and Symantec about this issue.
> > Amazon should remove the second intermediate, ending the path with the
> > G5 intermediate. This will allow openssl to find the trusted root CA.
> >
> > Also, Symantec
On Tue, 2014-09-09 at 15:28 +0200, Reindl Harald wrote:
> Am 09.09.2014 um 08:26 schrieb Adam Williamson:
> > certificate_list
> > This is a sequence (chain) of certificates. The sender's
> > certificate MUST come first in the list. Each following
> > certificate MUST directly c
Am 09.09.2014 um 08:26 schrieb Adam Williamson:
> certificate_list
> This is a sequence (chain) of certificates. The sender's
> certificate MUST come first in the list. Each following
> certificate MUST directly certify the one preceding it. Because
> certificate validat
On Mon, 2014-09-08 at 23:26 -0700, Adam Williamson wrote:
> certificate_list
> This is a sequence (chain) of certificates. The sender's
> certificate MUST come first in the list. Each following
> certificate MUST directly certify the one preceding it.
We recently learned the h
On Tue, 2014-09-09 at 10:34 +0200, Nikos Mavrogiannopoulos wrote:
> On Mon, 2014-09-08 at 23:26 -0700, Adam Williamson wrote:
> > On Mon, 2014-09-08 at 09:00 -0500, Michael Catanzaro wrote:
> > > On Mon, 2014-09-08 at 10:06 +0200, Nikos Mavrogiannopoulos wrote:
> > > > Unfortunately only NSS works.
On Mon, 2014-09-08 at 23:26 -0700, Adam Williamson wrote:
> On Mon, 2014-09-08 at 09:00 -0500, Michael Catanzaro wrote:
> > On Mon, 2014-09-08 at 10:06 +0200, Nikos Mavrogiannopoulos wrote:
> > > Unfortunately only NSS works. Both openssl and gnutls fail to connect to
> > > popular sites because of
On Mon, 2014-09-08 at 09:00 -0500, Michael Catanzaro wrote:
> On Mon, 2014-09-08 at 10:06 +0200, Nikos Mavrogiannopoulos wrote:
> > Unfortunately only NSS works. Both openssl and gnutls fail to connect to
> > popular sites because of that change. It should not be assumed that the
> > users of ca-ce
On Mon, 2014-09-08 at 10:06 +0200, Nikos Mavrogiannopoulos wrote:
> Unfortunately only NSS works. Both openssl and gnutls fail to connect to
> popular sites because of that change. It should not be assumed that the
> users of ca-certificates are only programs using nss.
No-one working on ca-certi
On Mon, 2014-09-08 at 17:07 +0200, Nikos Mavrogiannopoulos wrote:
> I understand but this is not the case here. The internet isn't broken
> because of gnutls and openssl have some limitation, but because the
> current NSS derived ca-certificates work assume the NSS validation
> strategy. This shoul
On Mon, 2014-09-08 at 09:00 -0500, Michael Catanzaro wrote:
> > I guess this is verification based on the rfc5280 path validation.
> > Unlike that NSS ignores the provided trust chain and tries to construct
> > a new one internally. That's interesting and happens to work around the
> > issue here
On Mon, 2014-09-08 at 10:06 +0200, Nikos Mavrogiannopoulos wrote:
> Unfortunately only NSS works. Both openssl and gnutls fail to connect to
> popular sites because of that change. It should not be assumed that the
> users of ca-certificates are only programs using nss.
[1] is an interesting read.
Dne 6.9.2014 01:58, Kai Engert napsal(a):
> On Tue, 2014-08-26 at 12:36 +0200, Vít Ondruch wrote:
>> $ gem fetch power_assert
>> ERROR: Could not find a valid gem 'power_assert' (>= 0), here is why:
>> Unable to download data from https://rubygems.org/ -
>> SSL_connect returned=1 errno=0
On Sat, 2014-09-06 at 01:58 +0200, Kai Engert wrote:
> The failure is with the s3.amazonaws.com host.
> Looking at the certificates the server sends:
> $ openssl s_client -showcerts -connect s3.amazonaws.com:443 2>&1 \
> |egrep " s:| i:"
> 0 s:/C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./CN
On Mon, 2014-09-01 at 18:03 -0500, Michael Catanzaro wrote:
> This update has caused a lot of pain for Epiphany. Could you take a look
> at [1] when you get a chance and help us figure out what's gone wrong?
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1134602#c3
Sorry for the delay. I've
On Tue, 2014-08-26 at 12:36 +0200, Vít Ondruch wrote:
> $ gem fetch power_assert
> ERROR: Could not find a valid gem 'power_assert' (>= 0), here is why:
> Unable to download data from https://rubygems.org/ -
> SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B:
> certif
On Mon, 2014-08-18 at 23:48 +0200, Kai Engert wrote:
> Hello,
>
> this is a heads-up for an update to the ca-certificates package that
> I've just submitted for updates-testing for Fedora 19 and 20.
>
> The upstream Mozilla CA list maintainers have decided to start removing
> CA certificates that
Dne 26.8.2014 17:00, Eric H. Christensen napsal(a):
> On Tue, Aug 26, 2014 at 12:36:47PM +0200, Vít Ondruch wrote:
> > $ gem fetch power_assert
> > ERROR: Could not find a valid gem 'power_assert' (>= 0), here is why:
> > Unable to download data from https://rubygems.org/ -
> > SSL_conne
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, Aug 26, 2014 at 12:36:47PM +0200, Vít Ondruch wrote:
> $ gem fetch power_assert
> ERROR: Could not find a valid gem 'power_assert' (>= 0), here is why:
> Unable to download data from https://rubygems.org/ -
> SSL_connect returned=1
Hi Kay,
This update has potential to break RubyGems with error:
$ gem fetch power_assert
ERROR: Could not find a valid gem 'power_assert' (>= 0), here is why:
Unable to download data from https://rubygems.org/ -
SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B:
cer
- Original Message -
> On Tue, 2014-08-19 at 10:07 -0400, Miloslav Trmač wrote:
> > That’s the right thing to do of course, but leaves the users with an
> > unusable system in the mean time. Could the update description at
> > least generally point to how to work around this if the certifi
On Tue, 2014-08-19 at 10:07 -0400, Miloslav Trmač wrote:
> That’s the right thing to do of course, but leaves the users with an
> unusable system in the mean time. Could the update description at
> least generally point to how to work around this if the certificate
> owner is not (sufficiently qui
On Tue, 2014-08-19 at 10:07 -0400, Miloslav Trmač wrote:
> - Original Message -
> > If you experience such situations, the right approach is to contact the
> > owner of the certificate (or the server), and ask them to get a
> > replacement certificate, or to install a replacement certificat
- Original Message -
> If you experience such situations, the right approach is to contact the
> owner of the certificate (or the server), and ask them to get a
> replacement certificate, or to install a replacement certificate on
> their SSL/TLS server.
That’s the right thing to do of cou
Hello,
this is a heads-up for an update to the ca-certificates package that
I've just submitted for updates-testing for Fedora 19 and 20.
The upstream Mozilla CA list maintainers have decided to start removing
CA certificates that use a weak 1024-bit key. Although those
certificates are still val
41 matches
Mail list logo
