RE: Call for testing new Launchpad Translations code performance

["Philippe Verdy" <verdy_p@xxxxxxxxxx>]

> -----Message d'origine-----
> De : launchpad-users-bounces@xxxxxxxxxxxxxxxxxxx [mailto:launchpad-users-
> bounces@xxxxxxxxxxxxxxxxxxx] De la part de Carlos Perelló Marín
> Envoyé : mercredi 21 novembre 2007 12:41
> À : Ubuntu translators
> Cc : launchpad-users
> Objet : Call for testing new Launchpad Translations code performance
> 
> Hi,
> 
> As part of this development cycle in Launchpad, we are deploying a
> performance improvement in Launchpad Translations that should fix most
> of the timeouts that you have been experiencing.
> 
> Our current testing is showing a wonderful improvement. However we would
> like to ask you for some input on this new performance improvement to be
> sure it's as good as it should be.
> 
> The procedure to help us test this before we deploy it tomorrow is
> simple: every time you get a timeout error while working with
> launchpad.net please, visit the same url but adding 'staging' to it.


The security certificate for connecting on the "staging" server is invalid:
it tries to use an address for which the certificate was not emitted!

Note that the certificate allows ONLY:
Domain=launchpad.net.
Domain=*.launchpad.net.

The latest indicates that only a single HOST label is permitted within the
main domain launchpad.net, but the certificate does not allow these labels
to be subdomains (it would require an additional permission to permit the
DNS server that hosts the subdomain "staging.lauchpad.net.").

In other words, the site certificate tries to use the certificate emitted
for HOSTS in the domain "lauchpad.net." for hosts in a DISTINCT domain
"staging.launchpad.net." and that necessarily uses a distinct set of primary
DNS servers with distinct administration.

Note that the identity of the owner of "launchpad.net." is asserted from the
".net" top-level registry where it was registered; on the opposite
"staging.launchpad.net" is a private entry managed in your own DNS server
without any reference to the ".net." registry authority, so the source of
identity is different. This explains why the certificate is rejected.

For a certificate to be usable in a subdomain, you need to emit your own
certificate for the subdomain, and sign it using an authority hosted on your
main domain "launchpad.net": this new certificate becomes usable if it is
signed using the certificate emitted for the main site. This means that you
need to create a chained certificate.

More generally, chaining SOAs for delegating the management of security in a
subdomain requires a complex setting, plus some extensive verification by
your existing certificate SOA for the main domain. For this reason, managing
secure sites (HTTPS) in subdomains should be avoided, especially if the
subdomain and its hosts is not registered within the same DNS servers as
your main domain.

Another solution would be to avoid using a subdomain for your staging site:
replace the dot "." before ".staging.launchpad.net" by a hyphen "-", and
register the staging hosts directly with the "-staging" label extension
within your main domain.

So I suggest you register the "translations-staging.launchpad.net" host in
your main domain and use it instead of "translations.staging.launchpad.net"
(using an unsecure subdomain), because this won't require installing another
chained certificate (managed by your own local source of authority), if you
don't have a local source of authority (note that your site certificate does
not declare that the certificate is usable as a valid SOA for a subdomain,
as this would become a security risk by permitting you to host sites
considered "secured" but managed by others than you at launchpad.net: they
would create SOAs at will if it was allowed, so this kind of certificate is
expensive to get and verify by your existing certificate emitter)...