[gentoo-user] broken seamonkey :(

[gentoo-user] broken seamonkey :(

[lee]

Hi,

since quite a while, seamonkey and its relatives are completely broken
when it comes to use self-signed certificates.  They just refuse the
connection to the server, blocking you from accessing your email.

Is there still no solution for this problem?  I'm totally fed up with it
by now.  At work, I have frozen seamonkey at version 2.31 and
thunderbird at some outdated version that still works with the
certificates.  Googling for a solution doesn't reveal one, either.

Now I need seamonkey to access the email, and I can't very well turn it
back to an outdated version just for that.

BTW, if this won't be fixed, what are the replacements?


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] broken seamonkey :(

[Fernando Rodriguez]

On Thursday, September 03, 2015 9:53:39 PM lee wrote:
> Hi,
> 
> since quite a while, seamonkey and its relatives are completely broken
> when it comes to use self-signed certificates.  They just refuse the
> connection to the server, blocking you from accessing your email.
> 
> Is there still no solution for this problem?  I'm totally fed up with it
> by now.  At work, I have frozen seamonkey at version 2.31 and
> thunderbird at some outdated version that still works with the
> certificates.  Googling for a solution doesn't reveal one, either.
> 
> Now I need seamonkey to access the email, and I can't very well turn it
> back to an outdated version just for that.
> 
> BTW, if this won't be fixed, what are the replacements?

This[1] is for firefox but should work similarly. Scroll all the way down to 
"bypassing the warning". There's also an about:config option, I *think* it's 
this one[2].

[1] https://support.mozilla.org/en-US/kb/connection-untrusted-error-message
[2] http://kb.mozillazine.org/Browser.ssl_override_behavior

-- 
Fernando Rodriguez

Re: [gentoo-user] broken seamonkey :(

[lee]

Fernando Rodriguez <frodriguez.developer@outlook.com> writes:

> On Thursday, September 03, 2015 9:53:39 PM lee wrote:
>> Hi,
>> 
>> since quite a while, seamonkey and its relatives are completely broken
>> when it comes to use self-signed certificates.  They just refuse the
>> connection to the server, blocking you from accessing your email.
>> 
>> Is there still no solution for this problem?  I'm totally fed up with it
>> by now.  At work, I have frozen seamonkey at version 2.31 and
>> thunderbird at some outdated version that still works with the
>> certificates.  Googling for a solution doesn't reveal one, either.
>> 
>> Now I need seamonkey to access the email, and I can't very well turn it
>> back to an outdated version just for that.
>> 
>> BTW, if this won't be fixed, what are the replacements?
>
> This[1] is for firefox but should work similarly. Scroll all the way down to 
> "bypassing the warning". There's also an about:config option, I *think* it's 
> this one[2].

Thank you.  The problem is that it doesn't let me add an exception. Only
the older versions do that.  All options to add an exception are
disabled.

There is 'browser.ssl_override_behavior', the value of which is
2. Guessing by what that means from [2], that should allow me to add an
exception.

'browser.xul.error_pages.enabled' is enabled.  There's also
'browser.xul.error_pages.expert_bad_cert', which is disabled.  Let's see
what that does ...  still cannot add an exception when I enable it.  [3]
would indicate that it's advisable to set it to "true".

Restarting seamonkey after changing it doesn't help.

There's nothing wrong with the certificate, either.  Older version work
just fine with it.  Mutt works fine with it.  Gnus works fine with it.
Evolution works fine with it.  All of those are more recent than
seamonkey 2.31.

I could resort to unencrypted connections on the LAN to be able to
upgrade the browsers and MUAs --- for security reasons, ironically ---
but some ppl with laptops need to be able to connect from anywhere over
the internet.  So omit all security and use VPN for those to make things
more secure by not using self-signed certificates but insecure
connections?


[3]: http://kb.mozillazine.org/Browser.xul.error_pages.expert_bad_cert

>
> [1] https://support.mozilla.org/en-US/kb/connection-untrusted-error-message
> [2] http://kb.mozillazine.org/Browser.ssl_override_behavior

-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] broken seamonkey :(

[Fernando Rodriguez]

On Friday, September 04, 2015 1:39:46 AM lee wrote:
> Fernando Rodriguez <frodriguez.developer@outlook.com> writes:
> 
> > On Thursday, September 03, 2015 9:53:39 PM lee wrote:
> >> Hi,
> >> 
> >> since quite a while, seamonkey and its relatives are completely broken
> >> when it comes to use self-signed certificates.  They just refuse the
> >> connection to the server, blocking you from accessing your email.
> >> 
> >> Is there still no solution for this problem?  I'm totally fed up with it
> >> by now.  At work, I have frozen seamonkey at version 2.31 and
> >> thunderbird at some outdated version that still works with the
> >> certificates.  Googling for a solution doesn't reveal one, either.
> >> 
> >> Now I need seamonkey to access the email, and I can't very well turn it
> >> back to an outdated version just for that.
> >> 
> >> BTW, if this won't be fixed, what are the replacements?
> >
> > This[1] is for firefox but should work similarly. Scroll all the way down 
to 
> > "bypassing the warning". There's also an about:config option, I *think* 
it's 
> > this one[2].
> 
> Thank you.  The problem is that it doesn't let me add an exception. Only
> the older versions do that.  All options to add an exception are
> disabled.
> 
> There is 'browser.ssl_override_behavior', the value of which is
> 2. Guessing by what that means from [2], that should allow me to add an
> exception.
> 
> 'browser.xul.error_pages.enabled' is enabled.  There's also
> 'browser.xul.error_pages.expert_bad_cert', which is disabled.  Let's see
> what that does ...  still cannot add an exception when I enable it.  [3]
> would indicate that it's advisable to set it to "true".
> 
> Restarting seamonkey after changing it doesn't help.
> 
> There's nothing wrong with the certificate, either.  Older version work
> just fine with it.  Mutt works fine with it.  Gnus works fine with it.
> Evolution works fine with it.  All of those are more recent than
> seamonkey 2.31.
> 
> I could resort to unencrypted connections on the LAN to be able to
> upgrade the browsers and MUAs --- for security reasons, ironically ---
> but some ppl with laptops need to be able to connect from anywhere over
> the internet.  So omit all security and use VPN for those to make things
> more secure by not using self-signed certificates but insecure
> connections?
> 
> 
> [3]: http://kb.mozillazine.org/Browser.xul.error_pages.expert_bad_cert
> 
> >
> > [1] https://support.mozilla.org/en-US/kb/connection-untrusted-error-message
> > [2] http://kb.mozillazine.org/Browser.ssl_override_behavior
> 
> 

I got the same settings as yours on firefox 40 and it lets me add exceptions so 
it must be a seamonkey thing. I think I remember this happening with an 
earlier firefox, I don't remember how I fixed it or if it fixed itself after an 
update. Maybe you can add your cert to mozilla's store:

http://www.cyberciti.biz/faq/firefox-adding-trusted-ca/



-- 
Fernando Rodriguez

Re: [gentoo-user] broken seamonkey :(

[Dale]

lee wrote:
> Fernando Rodriguez <frodriguez.developer@outlook.com> writes:
>
>> On Thursday, September 03, 2015 9:53:39 PM lee wrote:
>>> Hi,
>>>
>>> since quite a while, seamonkey and its relatives are completely broken
>>> when it comes to use self-signed certificates.  They just refuse the
>>> connection to the server, blocking you from accessing your email.
>>>
>>> Is there still no solution for this problem?  I'm totally fed up with it
>>> by now.  At work, I have frozen seamonkey at version 2.31 and
>>> thunderbird at some outdated version that still works with the
>>> certificates.  Googling for a solution doesn't reveal one, either.
>>>
>>> Now I need seamonkey to access the email, and I can't very well turn it
>>> back to an outdated version just for that.
>>>
>>> BTW, if this won't be fixed, what are the replacements?
>> This[1] is for firefox but should work similarly. Scroll all the way down to 
>> "bypassing the warning". There's also an about:config option, I *think* it's 
>> this one[2].
> Thank you.  The problem is that it doesn't let me add an exception. Only
> the older versions do that.  All options to add an exception are
> disabled.
>
> There is 'browser.ssl_override_behavior', the value of which is
> 2. Guessing by what that means from [2], that should allow me to add an
> exception.
>
> 'browser.xul.error_pages.enabled' is enabled.  There's also
> 'browser.xul.error_pages.expert_bad_cert', which is disabled.  Let's see
> what that does ...  still cannot add an exception when I enable it.  [3]
> would indicate that it's advisable to set it to "true".
>
> Restarting seamonkey after changing it doesn't help.
>
> There's nothing wrong with the certificate, either.  Older version work
> just fine with it.  Mutt works fine with it.  Gnus works fine with it.
> Evolution works fine with it.  All of those are more recent than
> seamonkey 2.31.
>
> I could resort to unencrypted connections on the LAN to be able to
> upgrade the browsers and MUAs --- for security reasons, ironically ---
> but some ppl with laptops need to be able to connect from anywhere over
> the internet.  So omit all security and use VPN for those to make things
> more secure by not using self-signed certificates but insecure
> connections?
>
>
> [3]: http://kb.mozillazine.org/Browser.xul.error_pages.expert_bad_cert
>
>> [1] https://support.mozilla.org/en-US/kb/connection-untrusted-error-message
>> [2] http://kb.mozillazine.org/Browser.ssl_override_behavior


I'm using seamonkey-2.33.1-r1 and I have not run into this problem.  If
you would like, I can check some settings and compare them to mine to
see if it would help fix yours.  Just let me know what you need. 

Surely this can be fixed.  Maybe I did something and don't recall it??

Dale

:-)  :-) 

Re: [gentoo-user] broken seamonkey :(

[Peter Weilbacher]

On Fri, 4 Sep 2015, lee wrote:

> Thank you.  The problem is that it doesn't let me add an exception. Only
> the older versions do that.  All options to add an exception are
> disabled.
>
> There is 'browser.ssl_override_behavior', the value of which is
> 2. Guessing by what that means from [2], that should allow me to add an
> exception.

Are you sure that diving right into about:config is the best way? In
SeaMonkey, take a look under Preferences -> Privacy & Security ->
Certificates. Under "Manage Certificates..." you can import your own
certificates which I think is the right way to proceed (although I
haven't tried that in a while). In the same dialog, you can also
manually add exceptions before you even go to the server.
Firefox and Thunderbird have similar dialogs.

   Peter.

Re: [gentoo-user] broken seamonkey :(

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1439 bytes --]

On Friday 04 Sep 2015 08:54:19 Peter Weilbacher wrote:

> Are you sure that diving right into about:config is the best way? In
> SeaMonkey, take a look under Preferences -> Privacy & Security ->
> Certificates. Under "Manage Certificates..." you can import your own
> certificates which I think is the right way to proceed (although I
> haven't tried that in a while). In the same dialog, you can also
> manually add exceptions before you even go to the server.
> Firefox and Thunderbird have similar dialogs.
> 
>    Peter.

I agree with Peter, it is best you don't disable what is after all a security 
warning mechanism.  

In Firefox you are not able to add an exception if you use a Private window 
(Ctrl+Shift+P).  Otherwise you should be able to.  Alternatively, have you 
tried adding an exception to the server certificate manually as suggested by 
Peter?

You can:

Add your self-signed server certificate in your Server certificates seamonkey 
tab.  Updating the seamonkey version ought to retain any certificates you have 
uploaded there.  You can also set an exception in the Server's tab.  If you do 
not have the server certificate already on your filesystem, you can obtain it 
with:

 openssl s_client -connect www.google.com:443 -showcerts

(replace www.google.com with your server of course).  

Or, you can try adding it in the RootCA tab and edit its trust there.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] broken seamonkey :(

[lee]

Mick <michaelkintzios@gmail.com> writes:

> On Friday 04 Sep 2015 08:54:19 Peter Weilbacher wrote:
>
>> Are you sure that diving right into about:config is the best way? In
>> SeaMonkey, take a look under Preferences -> Privacy & Security ->
>> Certificates. Under "Manage Certificates..." you can import your own
>> certificates which I think is the right way to proceed (although I
>> haven't tried that in a while). In the same dialog, you can also
>> manually add exceptions before you even go to the server.
>> Firefox and Thunderbird have similar dialogs.
>> 
>>    Peter.
>
> I agree with Peter, it is best you don't disable what is after all a security 
> warning mechanism.  
>
> In Firefox you are not able to add an exception if you use a Private window 
> (Ctrl+Shift+P).  Otherwise you should be able to.  Alternatively, have you 
> tried adding an exception to the server certificate manually as suggested by 
> Peter?
>
> You can:
>
> Add your self-signed server certificate in your Server certificates seamonkey 
> tab.  Updating the seamonkey version ought to retain any certificates you have 
> uploaded there.  You can also set an exception in the Server's tab.  If you do 
> not have the server certificate already on your filesystem, you can obtain it 
> with:
>
>  openssl s_client -connect www.google.com:443 -showcerts
>
> (replace www.google.com with your server of course).  
>
> Or, you can try adding it in the RootCA tab and edit its trust there.

It doesn't work.  I've imported the certificate now at home, and no
matter what trust I set or whatever I do, I cannot connect, and I cannot
add an exception.

I think I need to be able to add an exception through the dialog that
pops up when trying to connect since that's the only way that there's a
chance that it will work.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] broken seamonkey :(

[Fernando Rodriguez]

On Friday, September 04, 2015 9:50:43 PM lee wrote:
> Mick <michaelkintzios@gmail.com> writes:
> 
> > On Friday 04 Sep 2015 08:54:19 Peter Weilbacher wrote:
> >
> >> Are you sure that diving right into about:config is the best way? In
> >> SeaMonkey, take a look under Preferences -> Privacy & Security ->
> >> Certificates. Under "Manage Certificates..." you can import your own
> >> certificates which I think is the right way to proceed (although I
> >> haven't tried that in a while). In the same dialog, you can also
> >> manually add exceptions before you even go to the server.
> >> Firefox and Thunderbird have similar dialogs.
> >> 
> >>    Peter.
> >
> > I agree with Peter, it is best you don't disable what is after all a 
security 
> > warning mechanism.  
> >
> > In Firefox you are not able to add an exception if you use a Private 
window 
> > (Ctrl+Shift+P).  Otherwise you should be able to.  Alternatively, have you 
> > tried adding an exception to the server certificate manually as suggested 
by 
> > Peter?
> >
> > You can:
> >
> > Add your self-signed server certificate in your Server certificates 
seamonkey 
> > tab.  Updating the seamonkey version ought to retain any certificates you 
have 
> > uploaded there.  You can also set an exception in the Server's tab.  If 
you do 
> > not have the server certificate already on your filesystem, you can obtain 
it 
> > with:
> >
> >  openssl s_client -connect www.google.com:443 -showcerts
> >
> > (replace www.google.com with your server of course).  
> >
> > Or, you can try adding it in the RootCA tab and edit its trust there.
> 
> It doesn't work.  I've imported the certificate now at home, and no
> matter what trust I set or whatever I do, I cannot connect, and I cannot
> add an exception.

Did you tried under both "My Certificates" and "Authorities" tags (or whatever 
they're called on your version. For the Authorities/RootCA one you'll want to 
install your CA public cert that *should* allow all certificates that you issue 
to work. Under "My Certificates" you want the site certificate.

As for not being able to add exceptions, are you using the same version that 
is known to work for Dale?
I think this was a change that firefox tried to push and then reverted.

> I think I need to be able to add an exception through the dialog that
> pops up when trying to connect since that's the only way that there's a
> chance that it will work.
> 
> 
> 

-- 
Fernando Rodriguez

Re: [gentoo-user] broken seamonkey :(

[lee]

Fernando Rodriguez <frodriguez.developer@outlook.com> writes:

> On Friday, September 04, 2015 9:50:43 PM lee wrote:
>> Mick <michaelkintzios@gmail.com> writes:
>> 
>> > On Friday 04 Sep 2015 08:54:19 Peter Weilbacher wrote:
>> >
>> >> Are you sure that diving right into about:config is the best way? In
>> >> SeaMonkey, take a look under Preferences -> Privacy & Security ->
>> >> Certificates. Under "Manage Certificates..." you can import your own
>> >> certificates which I think is the right way to proceed (although I
>> >> haven't tried that in a while). In the same dialog, you can also
>> >> manually add exceptions before you even go to the server.
>> >> Firefox and Thunderbird have similar dialogs.
>> >> 
>> >>    Peter.
>> >
>> > I agree with Peter, it is best you don't disable what is after all a 
> security 
>> > warning mechanism.  
>> >
>> > In Firefox you are not able to add an exception if you use a Private 
> window 
>> > (Ctrl+Shift+P).  Otherwise you should be able to.  Alternatively, have you 
>> > tried adding an exception to the server certificate manually as suggested 
> by 
>> > Peter?
>> >
>> > You can:
>> >
>> > Add your self-signed server certificate in your Server certificates 
> seamonkey 
>> > tab.  Updating the seamonkey version ought to retain any certificates you 
> have 
>> > uploaded there.  You can also set an exception in the Server's tab.  If 
> you do 
>> > not have the server certificate already on your filesystem, you can obtain 
> it 
>> > with:
>> >
>> >  openssl s_client -connect www.google.com:443 -showcerts
>> >
>> > (replace www.google.com with your server of course).  
>> >
>> > Or, you can try adding it in the RootCA tab and edit its trust there.
>> 
>> It doesn't work.  I've imported the certificate now at home, and no
>> matter what trust I set or whatever I do, I cannot connect, and I cannot
>> add an exception.
>
> Did you tried under both "My Certificates"

There's no tab labled "My Certifiactes".  There's "Your Certificates"
(which would be "mine", I guess), described as ones from organizations
that describe me (of which there are none but myself, if it comes to
that).

When I try to import the certificate I obtained with openssl as above on
that tab, it says that the certificate cannot be installed because I "do
not own the private key which was created when the certificate was
requested" --- whatever that means.

> and "Authorities" tags (or whatever 
> they're called on your version. For the Authorities/RootCA one you'll want to 
> install your CA public cert that *should* allow all certificates that you issue 
> to work.

I can import it there and it makes no difference.  With the certificate
installed under "Authorities", I'm still being asked to add an exception
when I try to connect, and the buttons to add an exception are still
disabled.

> Under "My Certificates" you want the site certificate.

I don't understand: What is a site certificate?  I don't have any other
than I can download with openssl as described above.  The usual
procedure is to add an exception through the dialog that pops up for
that purpose, and that's all there is to it.  The problem is that it
doesn't let me add an exception.

Generally, an organization which provides email services to me is hardly
an organization that would manufacture a certificate that describes me
specifically in order to provide the service.  (I'm trying to connect to
the IMAP server via SSL/TLS on port 993.)

In this case, I happen to have full physical access to the server and
thus to the certificate stored on it.  This is not the case for, let's
say, an employee checking his work-email from home whom I might give the
login-data on the phone and instruct to add an exception when the dialog
to do so pops up when they are trying to connect.

When I connect to that same IMAP server with "mutt -f
imaps://example.com', mutt asks me whether I want to reject the
certificate or accept it once or always.  So I say once or always and
can log in.  It's as simple as that, no site certificate or anything but
my username and password are needed.

What is the problem with seamonkey and its relatives?

> As for not being able to add exceptions, are you using the same version that 
> is known to work for Dale?

He said he's using 2.33.1-r1.  'eix seamonkey' here shows

www-client/seamonkey
Installed versions:  2.33.1-r1

so I'm using the same.

> I think this was a change that firefox tried to push and then reverted.

If it was, it was, to put it nicely, an extremely bad idea.  Is there a
more recent version of seamonkey that works again?

I can (have to) do with seamonkey 2.30 at work and mutt at home.  This
isn't a long-term solution because it forbids updating the web browser
and email clients for everyone at work ever since.

Is this a bug of seamonkey?  I could make a bug report in that case.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] broken seamonkey :(

[Fernando Rodriguez]

On Saturday, September 05, 2015 1:05:06 AM lee wrote:
> Fernando Rodriguez <frodriguez.developer@outlook.com> writes:
> 
> > On Friday, September 04, 2015 9:50:43 PM lee wrote:
> >> Mick <michaelkintzios@gmail.com> writes:
> >> 
> >> > On Friday 04 Sep 2015 08:54:19 Peter Weilbacher wrote:
> >> >
> >> >> Are you sure that diving right into about:config is the best way? In
> >> >> SeaMonkey, take a look under Preferences -> Privacy & Security ->
> >> >> Certificates. Under "Manage Certificates..." you can import your own
> >> >> certificates which I think is the right way to proceed (although I
> >> >> haven't tried that in a while). In the same dialog, you can also
> >> >> manually add exceptions before you even go to the server.
> >> >> Firefox and Thunderbird have similar dialogs.
> >> >> 
> >> >>    Peter.
> >> >
> >> > I agree with Peter, it is best you don't disable what is after all a 
> > security 
> >> > warning mechanism.  
> >> >
> >> > In Firefox you are not able to add an exception if you use a Private 
> > window 
> >> > (Ctrl+Shift+P).  Otherwise you should be able to.  Alternatively, have 
you 
> >> > tried adding an exception to the server certificate manually as 
suggested 
> > by 
> >> > Peter?
> >> >
> >> > You can:
> >> >
> >> > Add your self-signed server certificate in your Server certificates 
> > seamonkey 
> >> > tab.  Updating the seamonkey version ought to retain any certificates 
you 
> > have 
> >> > uploaded there.  You can also set an exception in the Server's tab.  If 
> > you do 
> >> > not have the server certificate already on your filesystem, you can 
obtain 
> > it 
> >> > with:
> >> >
> >> >  openssl s_client -connect www.google.com:443 -showcerts
> >> >
> >> > (replace www.google.com with your server of course).  
> >> >
> >> > Or, you can try adding it in the RootCA tab and edit its trust there.
> >> 
> >> It doesn't work.  I've imported the certificate now at home, and no
> >> matter what trust I set or whatever I do, I cannot connect, and I cannot
> >> add an exception.
> >
> > Did you tried under both "My Certificates"
> 
> There's no tab labled "My Certifiactes".  There's "Your Certificates"
> (which would be "mine", I guess), described as ones from organizations
> that describe me (of which there are none but myself, if it comes to
> that).
> 
> When I try to import the certificate I obtained with openssl as above on
> that tab, it says that the certificate cannot be installed because I "do
> not own the private key which was created when the certificate was
> requested" --- whatever that means.
> 
> > and "Authorities" tags (or whatever 
> > they're called on your version. For the Authorities/RootCA one you'll want 
to 
> > install your CA public cert that *should* allow all certificates that you 
issue 
> > to work.
> 
> I can import it there and it makes no difference.  With the certificate
> installed under "Authorities", I'm still being asked to add an exception
> when I try to connect, and the buttons to add an exception are still
> disabled.
> 
> > Under "My Certificates" you want the site certificate.
> 
> I don't understand: What is a site certificate?  I don't have any other
> than I can download with openssl as described above.  The usual
> procedure is to add an exception through the dialog that pops up for
> that purpose, and that's all there is to it.  The problem is that it
> doesn't let me add an exception.
> 
> Generally, an organization which provides email services to me is hardly
> an organization that would manufacture a certificate that describes me
> specifically in order to provide the service.  (I'm trying to connect to
> the IMAP server via SSL/TLS on port 993.)
> 
> In this case, I happen to have full physical access to the server and
> thus to the certificate stored on it.  This is not the case for, let's
> say, an employee checking his work-email from home whom I might give the
> login-data on the phone and instruct to add an exception when the dialog
> to do so pops up when they are trying to connect.
> 
> When I connect to that same IMAP server with "mutt -f
> imaps://example.com', mutt asks me whether I want to reject the
> certificate or accept it once or always.  So I say once or always and
> can log in.  It's as simple as that, no site certificate or anything but
> my username and password are needed.
> 
> What is the problem with seamonkey and its relatives?
> 
> > As for not being able to add exceptions, are you using the same version 
that 
> > is known to work for Dale?
> 
> He said he's using 2.33.1-r1.  'eix seamonkey' here shows
> 
> www-client/seamonkey
> Installed versions:  2.33.1-r1
> 
> so I'm using the same.
> 
> > I think this was a change that firefox tried to push and then reverted.
> 
> If it was, it was, to put it nicely, an extremely bad idea.  Is there a
> more recent version of seamonkey that works again?
> 
> I can (have to) do with seamonkey 2.30 at work and mutt at home.  This
> isn't a long-term solution because it forbids updating the web browser
> and email clients for everyone at work ever since.
> 
> Is this a bug of seamonkey?  I could make a bug report in that case.

It is the servers tab, sorry. But I just tried and it still requires an 
exception.

Adding the CA certificate and ticking all trust options does work but it seems 
not all self-signed certs have one. If when you run openssl s_client -connect 
host:443 -showcerts it list more than one cert then you want to import the 
last under authorities.

You can try backing up and deleting your profile directory, if it works with a 
new one either go through all the ssl about:config settings and compare them or 
just start over with new settings and import bookmarks, etc. If you both have 
the same version then it must not be a change or bug.

-- 
Fernando Rodriguez

Re: [gentoo-user] broken seamonkey :(

[lee]

Fernando Rodriguez <frodriguez.developer@outlook.com> writes:

> On Saturday, September 05, 2015 1:05:06 AM lee wrote:
>> >> 
>> >> It doesn't work.  I've imported the certificate now at home, and no
>> >> matter what trust I set or whatever I do, I cannot connect, and I cannot
>> >> add an exception.
>> 
>> I can (have to) do with seamonkey 2.30 at work and mutt at home.  This
>> isn't a long-term solution because it forbids updating the web browser
>> and email clients for everyone at work ever since.
>> 
>> Is this a bug of seamonkey?  I could make a bug report in that case.
>
> Adding the CA certificate and ticking all trust options does work but it seems 
> not all self-signed certs have one.

It worked at work and didn't work at home.  It's weird.

> If when you run openssl s_client -connect 
> host:443 -showcerts it list more than one cert then you want to import the 
> last under authorities.

As far as I can tell, it shows only one certificate.  When I import it,
it shows up correctly.

> You can try backing up and deleting your profile directory, if it works with a 
> new one either go through all the ssl about:config settings and compare them or 
> just start over with new settings and import bookmarks, etc. If you both have 
> the same version then it must not be a change or bug.

It's not that.  I've tried it at work with a seamonkey on a windoze 7 VM
with a seamonkey that had only been used for web browsing and for which
I haven't changed any settings that could be even remotely related to
this.

The inability to add an exception is consistent over at least 5 totally
different machines, Linux and windoze, with at least seamonkey and
thunderbird.  On at least two of these machines, older versions like
seamonkey 2.30, simply let me add an exception while newer versions
don't.  Update seamonkey on the terminal server, create a new user, try
to set up seamonkey so that they can access their email, and you cannot
add an exception.  You have to revert to 2.30, add the exception, and
then you can go back to 2.33.1 and it works because the exception was
added.

So this must either be a bug of seamonkey and its relatives, or a
default setting that has changed with newer versions, or something needs
to be done with all(!) self-signed certificates, or adding exceptions
has been disabled intentionally, which would require another way to do
it because they cannot expect everyone to somehow change their perfectly
fine certificates or to buy signed ones.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] broken seamonkey :(

[Fernando Rodriguez]

On Saturday, September 05, 2015 1:05:06 AM lee wrote:
> In this case, I happen to have full physical access to the server and
> thus to the certificate stored on it.  This is not the case for, let's
> say, an employee checking his work-email from home whom I might give the
> login-data on the phone and instruct to add an exception when the dialog
> to do so pops up when they are trying to connect.

As a workaround you can create your own CA cert. I tested with a windows self-
signed cert (I guess the correct term is self-issued) and the openssl command 
will show two certs. The second is the CA.

http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certificate-authority/

-- 
Fernando Rodriguez

Re: [gentoo-user] broken seamonkey :(

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1370 bytes --]

On Saturday 05 Sep 2015 02:08:47 Fernando Rodriguez wrote:
> On Saturday, September 05, 2015 1:05:06 AM lee wrote:
> > In this case, I happen to have full physical access to the server and
> > thus to the certificate stored on it.  This is not the case for, let's
> > say, an employee checking his work-email from home whom I might give the
> > login-data on the phone and instruct to add an exception when the dialog
> > to do so pops up when they are trying to connect.
> 
> As a workaround you can create your own CA cert. I tested with a windows
> self- signed cert (I guess the correct term is self-issued) and the
> openssl command will show two certs. The second is the CA.
> 
> http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certificate
> -authority/

lee, on my FF I can import a self-signed certificate when I go to:

 about:preferences#advanced 

and then select the 'Servers' tab.  After I import it I can select it and 
click on the 'Add Exception' button at the bottom of the tab.  Enter the http 
address of the server and FF should go and fetch it afresh when you click on 
'Get Certificate', then tick 'Permanently store this exception' and 'Confirm 
Security Exception'.  These buttons will be greyed out if do not download the 
certificate or if I am running FF in Private Browsing mode.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] broken seamonkey :(

[lee]

[-- Attachment #1: Type: text/plain, Size: 2241 bytes --]

Mick <michaelkintzios@gmail.com> writes:

> On Saturday 05 Sep 2015 02:08:47 Fernando Rodriguez wrote:
>> On Saturday, September 05, 2015 1:05:06 AM lee wrote:
>> > In this case, I happen to have full physical access to the server and
>> > thus to the certificate stored on it.  This is not the case for, let's
>> > say, an employee checking his work-email from home whom I might give the
>> > login-data on the phone and instruct to add an exception when the dialog
>> > to do so pops up when they are trying to connect.
>> 
>> As a workaround you can create your own CA cert. I tested with a windows
>> self- signed cert (I guess the correct term is self-issued) and the
>> openssl command will show two certs. The second is the CA.
>> 
>> http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certificate
>> -authority/
>
> lee, on my FF I can import a self-signed certificate when I go to:
>
>  about:preferences#advanced 

You mean to enter this as an URL, just like about:config?  When I do
that, I'm getting "The URL is not valid and cannot be loaded. The
provided address is not in a recognized format. Please check the
location bar for mistakes and try again.".

Maybe that only works with firefox?

> and then select the 'Servers' tab.  After I import it I can select it and 
> click on the 'Add Exception' button at the bottom of the tab.  Enter the http 
> address of the server and FF should go and fetch it afresh when you click on 
> 'Get Certificate', then tick 'Permanently store this exception' and 'Confirm 
> Security Exception'.  These buttons will be greyed out if do not download the 
> certificate or if I am running FF in Private Browsing mode.

I'm guessing you might be in the window that shows up when you edit
preferences and go to 'Privacy & Security --> Certificates --> Manage
Certificates ...' and then to the "Servers" tab.

From there, I can import the certificate I downloaded with openssl.
Once imported, I can click on "Add Exceptions".  That gives me the same
dialog which comes up when I'm trying to connect which doesn't allow me
to add an exception because the buttons to do so are disabled.  The
dialog remains stuck at "Checking Information" indefinitely.

I'm attaching a screenshot:



[-- Attachment #2: seamonkey.jpg --]
[-- Type: image/jpeg, Size: 69294 bytes --]

[-- Attachment #3: Type: text/plain, Size: 136 bytes --]



-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] broken seamonkey :(

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 3269 bytes --]

On Saturday 05 Sep 2015 17:22:24 lee wrote:
> Mick <michaelkintzios@gmail.com> writes:
> > On Saturday 05 Sep 2015 02:08:47 Fernando Rodriguez wrote:
> >> On Saturday, September 05, 2015 1:05:06 AM lee wrote:
> >> > In this case, I happen to have full physical access to the server and
> >> > thus to the certificate stored on it.  This is not the case for, let's
> >> > say, an employee checking his work-email from home whom I might give
> >> > the login-data on the phone and instruct to add an exception when the
> >> > dialog to do so pops up when they are trying to connect.
> >> 
> >> As a workaround you can create your own CA cert. I tested with a windows
> >> self- signed cert (I guess the correct term is self-issued) and the
> >> openssl command will show two certs. The second is the CA.
> >> 
> >> http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certific
> >> ate -authority/
> > 
> > lee, on my FF I can import a self-signed certificate when I go to:
> >  about:preferences#advanced
> 
> You mean to enter this as an URL, just like about:config?  When I do
> that, I'm getting "The URL is not valid and cannot be loaded. The
> provided address is not in a recognized format. Please check the
> location bar for mistakes and try again.".
> 
> Maybe that only works with firefox?

Yes, it seems to be the case that SeaMonkey has some GUI differences to 
Firefox.  I am on Firefox-38.2.1 at present.


> > and then select the 'Servers' tab.  After I import it I can select it and
> > click on the 'Add Exception' button at the bottom of the tab.  Enter the
> > http address of the server and FF should go and fetch it afresh when you
> > click on 'Get Certificate', then tick 'Permanently store this exception'
> > and 'Confirm Security Exception'.  These buttons will be greyed out if
> > do not download the certificate or if I am running FF in Private
> > Browsing mode.
> 
> I'm guessing you might be in the window that shows up when you edit
> preferences and go to 'Privacy & Security --> Certificates --> Manage
> Certificates ...' and then to the "Servers" tab.

Yes, this is the location I am referring to.  However, if it is hanging and 
not connecting to the server to fetch the certificate something is not right.  
This is the reason with the exception button it greyed out.

I can't recall if you tried this:

Can you please remove it from Servers and try adding it to the Authorities 
tab?  Your version may have additional verification checks for self-signed 
certificates, because they essentially acting as their own Root CAs.


> From there, I can import the certificate I downloaded with openssl.
> Once imported, I can click on "Add Exceptions".  That gives me the same
> dialog which comes up when I'm trying to connect which doesn't allow me
> to add an exception because the buttons to do so are disabled.  The
> dialog remains stuck at "Checking Information" indefinitely.
> 
> I'm attaching a screenshot:

The fact that it is hanging and not obtaining the certificate makes me wonder 
if you need to specify a domain name in the CN field of the certificate, 
identical to the full URI that the client is trying to connect to.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] broken seamonkey :(

[lee]

Mick <michaelkintzios@gmail.com> writes:

> On Saturday 05 Sep 2015 17:22:24 lee wrote:
>> Mick <michaelkintzios@gmail.com> writes:
>> > On Saturday 05 Sep 2015 02:08:47 Fernando Rodriguez wrote:
>> >> On Saturday, September 05, 2015 1:05:06 AM lee wrote:
>> >> > In this case, I happen to have full physical access to the server and
>> >> > thus to the certificate stored on it.  This is not the case for, let's
>> >> > say, an employee checking his work-email from home whom I might give
>> >> > the login-data on the phone and instruct to add an exception when the
>> >> > dialog to do so pops up when they are trying to connect.
>> >> 
>> >> As a workaround you can create your own CA cert. I tested with a windows
>> >> self- signed cert (I guess the correct term is self-issued) and the
>> >> openssl command will show two certs. The second is the CA.
>> >> 
>> >> http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certific
>> >> ate -authority/
>> > 
>> > lee, on my FF I can import a self-signed certificate when I go to:
>> >  about:preferences#advanced
>> 
>> You mean to enter this as an URL, just like about:config?  When I do
>> that, I'm getting "The URL is not valid and cannot be loaded. The
>> provided address is not in a recognized format. Please check the
>> location bar for mistakes and try again.".
>> 
>> Maybe that only works with firefox?
>
> Yes, it seems to be the case that SeaMonkey has some GUI differences to 
> Firefox.  I am on Firefox-38.2.1 at present.

Does Firefox even have a MUA built in?  IIRC it's only the web browser
part of seamonkey.

>> > and then select the 'Servers' tab.  After I import it I can select it and
>> > click on the 'Add Exception' button at the bottom of the tab.  Enter the
>> > http address of the server and FF should go and fetch it afresh when you
>> > click on 'Get Certificate', then tick 'Permanently store this exception'
>> > and 'Confirm Security Exception'.  These buttons will be greyed out if
>> > do not download the certificate or if I am running FF in Private
>> > Browsing mode.
>> 
>> I'm guessing you might be in the window that shows up when you edit
>> preferences and go to 'Privacy & Security --> Certificates --> Manage
>> Certificates ...' and then to the "Servers" tab.
>
> Yes, this is the location I am referring to.  However, if it is hanging and 
> not connecting to the server to fetch the certificate something is not right.  
> This is the reason with the exception button it greyed out.
>
> I can't recall if you tried this:
>
> Can you please remove it from Servers and try adding it to the Authorities 
> tab?  Your version may have additional verification checks for self-signed 
> certificates, because they essentially acting as their own Root CAs.

Yes, I tried that.

>> From there, I can import the certificate I downloaded with openssl.
>> Once imported, I can click on "Add Exceptions".  That gives me the same
>> dialog which comes up when I'm trying to connect which doesn't allow me
>> to add an exception because the buttons to do so are disabled.  The
>> dialog remains stuck at "Checking Information" indefinitely.
>> 
>> I'm attaching a screenshot:
>
> The fact that it is hanging and not obtaining the certificate makes me wonder 
> if you need to specify a domain name in the CN field of the certificate, 
> identical to the full URI that the client is trying to connect to.

That brings us back to the impractical idea of trying to bind a
certificate to a specific fqdn or IP, or to a number of those.

Is it possible to create a certificate that doesn't use either but a
wildcard only?  I don't understand why or how an fqdn/IP in a
certificate could or should be relevant at all.

When creating the certificate, I have used the fqdn the host does
actually have and knows itself by (because I needed to fill in the
fields, and it seemed most reasonable to use the actual host name).

That this host can be reached at all, via different fqdns and IPs, is a
matter of network traffic (re-)direction and of how the DNS-entries
currently happen to be.  They are all transparent and irrelevant to the
user/client and subject to change.  Why should they matter for a
certificate which is supposed to let me figure out whether I'm
connecting to the host I'm expecting to connect to, or to something
else?

When a friend calls you on the phone, you do not insist that they are
not your friend and reject their call just because they're calling you
from a different phone number.  You do not reject their call and insist
that they are not your friend because the call has been (re-)directed
over a satellite or goes through an asterisk server.  You do not insist
that your friend is someone else when they show up at your door wearing
different cloths than they usually do.  Instead, you figure out that the
caller, or the person at your door, is your friend by the human
equivalent of a certificate.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] broken seamonkey :(

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 4346 bytes --]

On Sunday 06 Sep 2015 15:29:25 lee wrote:
> Mick <michaelkintzios@gmail.com> writes:
> > On Saturday 05 Sep 2015 17:22:24 lee wrote:

> >> Maybe that only works with firefox?
> > 
> > Yes, it seems to be the case that SeaMonkey has some GUI differences to
> > Firefox.  I am on Firefox-38.2.1 at present.
> 
> Does Firefox even have a MUA built in?  IIRC it's only the web browser
> part of seamonkey.

No, but T'bird uses the same SSL certificate storage as the mozilla browser 
does.


> > I can't recall if you tried this:
> > 
> > Can you please remove it from Servers and try adding it to the
> > Authorities tab?  Your version may have additional verification checks
> > for self-signed certificates, because they essentially acting as their
> > own Root CAs.
> 
> Yes, I tried that.

Right, I saw your email.  From what I can gather this is a bug impairing 
critical functionality of the Mozilla suite.


> > The fact that it is hanging and not obtaining the certificate makes me
> > wonder if you need to specify a domain name in the CN field of the
> > certificate, identical to the full URI that the client is trying to
> > connect to.
> 
> That brings us back to the impractical idea of trying to bind a
> certificate to a specific fqdn or IP, or to a number of those.
> 
> Is it possible to create a certificate that doesn't use either but a
> wildcard only?  I don't understand why or how an fqdn/IP in a
> certificate could or should be relevant at all.

It is relevant because Mozilla will read the CN and or subjectAltName fields 
for DNS/IP to match against the URL the client is trying to connect to.  It 
will also read any additional fields for OCSP and CRL URIs and try to connect 
to those too to retrieve relevant files (e.g. of revocation lists).  These 
would be contained in the certificate's X509v3 extensions.  The browser does 
not extrapolate from what is contained in those fields, but treats their 
contents literally.  If the CN field contains 'example.com' but the client is 
trying to connect to 'www.example.com' (or the server redirects to the latter) 
the browser's verification engine could throw its arms up and say STOP!  This 
is not the address specified on the certificate, therefore you could be 
inadvertently trying to connect to a malicious server impersonating your 
server.  The browser is warning about a Man In The Middle attack.  This is 
fine and as it should be.  What is not at all fine is that it stops you 
connecting AND it does not allow you to acknowledge as acceptable whatever it 
is that it doesn't like about your certificate.


> When creating the certificate, I have used the fqdn the host does
> actually have and knows itself by (because I needed to fill in the
> fields, and it seemed most reasonable to use the actual host name).
> 
> That this host can be reached at all, via different fqdns and IPs, is a
> matter of network traffic (re-)direction and of how the DNS-entries
> currently happen to be.  They are all transparent and irrelevant to the
> user/client and subject to change.  Why should they matter for a
> certificate which is supposed to let me figure out whether I'm
> connecting to the host I'm expecting to connect to, or to something
> else?
> 
> When a friend calls you on the phone, you do not insist that they are
> not your friend and reject their call just because they're calling you
> from a different phone number.  You do not reject their call and insist
> that they are not your friend because the call has been (re-)directed
> over a satellite or goes through an asterisk server.  You do not insist
> that your friend is someone else when they show up at your door wearing
> different cloths than they usually do.  Instead, you figure out that the
> caller, or the person at your door, is your friend by the human
> equivalent of a certificate.


Well, in the UK we have a feature called 'Caller ID'.  You will be surprised 
at the number of voice mails I have to leave when I call from a 'caller ID 
witheld' phone.  People will NOT answer unless they recognise the number of 
the caller.  :-)

With a server the FQDN is much more important, as it can impersonate e.g. you 
Bank and steal login information about your login details.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] broken seamonkey :(

[lee]

Mick <michaelkintzios@gmail.com> writes:

> On Sunday 06 Sep 2015 15:29:25 lee wrote:

> [...]
>> 
>> Is it possible to create a certificate that doesn't use either but a
>> wildcard only?  I don't understand why or how an fqdn/IP in a
>> certificate could or should be relevant at all.
>
> It is relevant because Mozilla will read the CN and or subjectAltName fields 
> for DNS/IP to match against the URL the client is trying to connect to.  It 
> will also read any additional fields for OCSP and CRL URIs and try to connect 
> to those too to retrieve relevant files (e.g. of revocation lists).  These 
> would be contained in the certificate's X509v3 extensions.  The browser does 
> not extrapolate from what is contained in those fields, but treats their 
> contents literally.  If the CN field contains 'example.com' but the client is 
> trying to connect to 'www.example.com' (or the server redirects to the latter) 
> the browser's verification engine could throw its arms up and say STOP!  This 
> is not the address specified on the certificate, therefore you could be 
> inadvertently trying to connect to a malicious server impersonating your 
> server.  The browser is warning about a Man In The Middle attack.  This is 
> fine and as it should be.

Thank you for the explanation.  I'm like entirely omitting this part
because when I do accept a certificate (i. e. add an exception), I have
done so.  That's all there is to it.

Actually, I'm doing it on a LAN.  I can look at the certificate and see
if it looks ok.  If there was someone in between me and the server, I'd
be having far more serious problems than not being able to add an
exception.  So the part I'm omitting isn't relevant as long as a warning
comes up when the certificate I previously accepted suddenly doesn't
match anymore.

But having that said, I probably need to change my way of thinking: If a
user goes somewhere with their laptop and gets that warning, chances are
that they will add an exception, and bad things might happen.

Using a CA certificate won't stop them, though.  Now what?

> What is not at all fine is that it stops you connecting AND it does
> not allow you to acknowledge as acceptable whatever it is that it
> doesn't like about your certificate.

Indeed --- fortunately, this problem is solved with seamonkey 2.35.


> [...]
>> When a friend calls you on the phone, you do not insist that they are
>> not your friend and reject their call just because they're calling you
>> from a different phone number.
> [...]
>
> Well, in the UK we have a feature called 'Caller ID'.  You will be surprised 
> at the number of voice mails I have to leave when I call from a 'caller ID 
> witheld' phone.  People will NOT answer unless they recognise the number of 
> the caller.  :-)

Some people do that here, too.  It's their problem, not mine.  Besides,
I was told that the caller number is easy to fake, which people found
relevant with faxes.

> With a server the FQDN is much more important, as it can impersonate e.g. you 
> Bank and steal login information about your login details.

Still I have no way to verify whether I'm connected to the server I
think I'm connected to or not (i. e. the bank or someone else).  Sure, I
might be asked to add an exception and thus be alarmed --- but unable to
verify.

So turning this the other way round: Can I *prevent* users from being
able to add an exception (at least by making it rather difficult for
them)?  Assuming that I would create a CA certificate and import it for
each user, and use certificates signed with it, I'd like to have some
way to prevent them from adding exceptions.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] broken seamonkey :(

[Fernando Rodriguez]

On Sunday, September 06, 2015 4:29:25 PM lee wrote:
> Mick <michaelkintzios@gmail.com> writes:
> 
> > On Saturday 05 Sep 2015 17:22:24 lee wrote:
> >> Mick <michaelkintzios@gmail.com> writes:
> >> > On Saturday 05 Sep 2015 02:08:47 Fernando Rodriguez wrote:
> >> >> On Saturday, September 05, 2015 1:05:06 AM lee wrote:
> >> >> > In this case, I happen to have full physical access to the server 
and
> >> >> > thus to the certificate stored on it.  This is not the case for, 
let's
> >> >> > say, an employee checking his work-email from home whom I might give
> >> >> > the login-data on the phone and instruct to add an exception when 
the
> >> >> > dialog to do so pops up when they are trying to connect.
> >> >> 
> >> >> As a workaround you can create your own CA cert. I tested with a 
windows
> >> >> self- signed cert (I guess the correct term is self-issued) and the
> >> >> openssl command will show two certs. The second is the CA.
> >> >> 
> >> >> http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certific
> >> >> ate -authority/
> >> > 
> >> > lee, on my FF I can import a self-signed certificate when I go to:
> >> >  about:preferences#advanced
> >> 
> >> You mean to enter this as an URL, just like about:config?  When I do
> >> that, I'm getting "The URL is not valid and cannot be loaded. The
> >> provided address is not in a recognized format. Please check the
> >> location bar for mistakes and try again.".
> >> 
> >> Maybe that only works with firefox?
> >
> > Yes, it seems to be the case that SeaMonkey has some GUI differences to 
> > Firefox.  I am on Firefox-38.2.1 at present.
> 
> Does Firefox even have a MUA built in?  IIRC it's only the web browser
> part of seamonkey.
> 
> >> > and then select the 'Servers' tab.  After I import it I can select it 
and
> >> > click on the 'Add Exception' button at the bottom of the tab.  Enter 
the
> >> > http address of the server and FF should go and fetch it afresh when 
you
> >> > click on 'Get Certificate', then tick 'Permanently store this exception'
> >> > and 'Confirm Security Exception'.  These buttons will be greyed out if
> >> > do not download the certificate or if I am running FF in Private
> >> > Browsing mode.
> >> 
> >> I'm guessing you might be in the window that shows up when you edit
> >> preferences and go to 'Privacy & Security --> Certificates --> Manage
> >> Certificates ...' and then to the "Servers" tab.
> >
> > Yes, this is the location I am referring to.  However, if it is hanging 
and 
> > not connecting to the server to fetch the certificate something is not 
right.  
> > This is the reason with the exception button it greyed out.
> >
> > I can't recall if you tried this:
> >
> > Can you please remove it from Servers and try adding it to the Authorities 
> > tab?  Your version may have additional verification checks for self-signed 
> > certificates, because they essentially acting as their own Root CAs.
> 
> Yes, I tried that.
> 
> >> From there, I can import the certificate I downloaded with openssl.
> >> Once imported, I can click on "Add Exceptions".  That gives me the same
> >> dialog which comes up when I'm trying to connect which doesn't allow me
> >> to add an exception because the buttons to do so are disabled.  The
> >> dialog remains stuck at "Checking Information" indefinitely.
> >> 
> >> I'm attaching a screenshot:
> >
> > The fact that it is hanging and not obtaining the certificate makes me 
wonder 
> > if you need to specify a domain name in the CN field of the certificate, 
> > identical to the full URI that the client is trying to connect to.
> 
> That brings us back to the impractical idea of trying to bind a
> certificate to a specific fqdn or IP, or to a number of those.
> 
> Is it possible to create a certificate that doesn't use either but a
> wildcard only?  I don't understand why or how an fqdn/IP in a
> certificate could or should be relevant at all.
> 
> When creating the certificate, I have used the fqdn the host does
> actually have and knows itself by (because I needed to fill in the
> fields, and it seemed most reasonable to use the actual host name).
> 
> That this host can be reached at all, via different fqdns and IPs, is a
> matter of network traffic (re-)direction and of how the DNS-entries
> currently happen to be.  They are all transparent and irrelevant to the
> user/client and subject to change.  Why should they matter for a
> certificate which is supposed to let me figure out whether I'm
> connecting to the host I'm expecting to connect to, or to something
> else?
> 
> When a friend calls you on the phone, you do not insist that they are
> not your friend and reject their call just because they're calling you
> from a different phone number.  You do not reject their call and insist
> that they are not your friend because the call has been (re-)directed
> over a satellite or goes through an asterisk server.  You do not insist
> that your friend is someone else when they show up at your door wearing
> different cloths than they usually do.  Instead, you figure out that the
> caller, or the person at your door, is your friend by the human
> equivalent of a certificate.

An SSL certificate provides both encryption and authentication. For the 
encryption part it's simple, you own the private key, the certificate has the 
public key, so only you can decrypt whatever is encrypted with it. 

Authentication is more complicated. It's easy if you think of if like a driver 
license. The hostname is like the photo, if I get pulled over and hand over a 
stolen license to the officer he'll know it's not me by looking at the photo. 
Your browser does the same with the hostname, if somebody steals your private 
key they will also have to steal your domain name to impersonate you. If 
somebody grabs a hold of your CA's private key is like stealing the DMV 
printer, now they can issue themselves a license with your name and their own 
picture. But if they hand it over to an officer he will call it in and find out 
it's fake, that's the equivalent of revocation lists and ocsp.

Of course it only works because we trust the DMV (or the CA in this case) to 
be diligent in verifying you are who you say you are before issuing a license 
or certificate. So it all doesn't apply as much to self issued certificates but 
it still applies to some extent.

-- 
Fernando Rodriguez

Re: [gentoo-user] broken seamonkey :(

[lee]

Fernando Rodriguez <frodriguez.developer@outlook.com> writes:

> On Sunday, September 06, 2015 4:29:25 PM lee wrote:

> [...]
>> 
>> When creating the certificate, I have used the fqdn the host does
>> actually have and knows itself by (because I needed to fill in the
>> fields, and it seemed most reasonable to use the actual host name).
>> 
>> That this host can be reached at all, via different fqdns and IPs, is a
>> matter of network traffic (re-)direction and of how the DNS-entries
>> currently happen to be.  They are all transparent and irrelevant to the
>> user/client and subject to change.  Why should they matter for a
>> certificate which is supposed to let me figure out whether I'm
>> connecting to the host I'm expecting to connect to, or to something
>> else?
> [...]
>
> An SSL certificate provides both encryption and authentication. For the 
> encryption part it's simple, you own the private key, the certificate has the 
> public key, so only you can decrypt whatever is encrypted with it. 
>
> Authentication is more complicated. It's easy if you think of if like a driver 
> license. The hostname is like the photo, if I get pulled over and hand over a 
> stolen license to the officer he'll know it's not me by looking at the photo. 
> Your browser does the same with the hostname, if somebody steals your private 
> key they will also have to steal your domain name to impersonate you. If 
> somebody grabs a hold of your CA's private key is like stealing the DMV 
> printer, now they can issue themselves a license with your name and their own 
> picture. But if they hand it over to an officer he will call it in and find out 
> it's fake, that's the equivalent of revocation lists and ocsp.
>
> Of course it only works because we trust the DMV (or the CA in this case) to 
> be diligent in verifying you are who you say you are before issuing a license 
> or certificate. So it all doesn't apply as much to self issued certificates but 
> it still applies to some extent.

Actually, it does not work.  What my face looks like is not subject to
network traffic (re-)direction and the content of DNS entries.  It
changes with age and can still be recognized.  I could send you a
picture of my face and you would never know whose face is on the
picture: that's like an FQDN or IP.  I could just as well give you an IP
address or FQDN to identify myself.

The purpose of driver licenses is not identification.  Anyway, why would
I need some sort of document to identify myself if my face would
suffice?  In practise, the document is more important than the face
that's on it.

IIRC, there is a way with gpg to change the email address(es) of your
key.  That makes sense because the address is for having the convenience
of not needing to specify a key-ID or something else.  And that I might
be using another email address does not invalidate the key.  It's the
key itself which is relevant, not what is being used to pick which key
to choose.

Linking a certificate to an FQDN or IP is clutching at straws at best.
As my face changes with time, they also do.  With documents to identify
me, I don't update the picture all the time.

When the ID-document I currently have expires, I won't have one that
hasn't expired because they have become so insanely expensive that I
can't afford one.  That's similar to the work it would take to put a new
certificate in place for all the users just because it's linked to an
FQDN/IP.  It might be cheaper if you could change out the picture as you
can change the email address with gpg.

The concept is flawed.  And how could I myself verify that a CA does its
job the way they are supposed to do it?  In the end, it's no more than a
deception, and that shouldn't be needed to be able to use encrypted
connections.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] broken seamonkey :(

[lee]

Fernando Rodriguez <frodriguez.developer@outlook.com> writes:

> On Saturday, September 05, 2015 1:05:06 AM lee wrote:
>> In this case, I happen to have full physical access to the server and
>> thus to the certificate stored on it.  This is not the case for, let's
>> say, an employee checking his work-email from home whom I might give the
>> login-data on the phone and instruct to add an exception when the dialog
>> to do so pops up when they are trying to connect.
>
> As a workaround you can create your own CA cert. I tested with a windows self-
> signed cert (I guess the correct term is self-issued) and the openssl command 
> will show two certs. The second is the CA.
>
> http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certificate-authority/

They're saying:


"Whatever you see in the address field in your browser when you go to
your device must be what you put under common name, even if it’s an IP
address.  [...]  If it doesn’t match, even a properly signed certificate
will not validate correctly and you’ll get the “cannot verify
authenticity” error."


What's the solution for a server which can be reached by different fqdns
and IPs?  What if the fqdns and IPs it can be reached by change over the
lifetime of the certificates?


How do I deploy some sort of central infrastructure all clients on the
LAN and anywhere on the world will automatically use to do the simple
thing of adding an exception (or whatever is required for that) so that
seamonkey and relatives can be used to access email?

That's letting aside that it's ridiculous to deploy such an
infrastructure when the same thing could be achieved by the user
clicking a button once to add an exception, as it used to be.


Seriously?  The result is currently a version freeze; the alternative is
using unencrypted connections.  After some time, the version freeze
cannot be kept up.  Since there are no alternative MUAs, we can only go
back to unencrypted connections when that happens.  And that's something
I don't even want to do on the LAN.


Well, I've made a bug report about this: https://bugzilla.mozilla.org/show_bug.cgi?id=1202128


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] broken seamonkey :(

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 3419 bytes --]

On Saturday 05 Sep 2015 14:06:27 lee wrote:
> Fernando Rodriguez <frodriguez.developer@outlook.com> writes:
> > On Saturday, September 05, 2015 1:05:06 AM lee wrote:
> >> In this case, I happen to have full physical access to the server and
> >> thus to the certificate stored on it.  This is not the case for, let's
> >> say, an employee checking his work-email from home whom I might give the
> >> login-data on the phone and instruct to add an exception when the dialog
> >> to do so pops up when they are trying to connect.
> > 
> > As a workaround you can create your own CA cert. I tested with a windows
> > self- signed cert (I guess the correct term is self-issued) and the
> > openssl command will show two certs. The second is the CA.
> > 
> > http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certifica
> > te-authority/
> 
> They're saying:
> 
> 
> "Whatever you see in the address field in your browser when you go to
> your device must be what you put under common name, even if it’s an IP
> address.  [...]  If it doesn’t match, even a properly signed certificate
> will not validate correctly and you’ll get the “cannot verify
> authenticity” error."
> 
> 
> What's the solution for a server which can be reached by different fqdns
> and IPs?  What if the fqdns and IPs it can be reached by change over the
> lifetime of the certificates?

If we are talking about changing subdomains, e.g. mailserver1.mydomain.com and 
mailserver2.mydomain.com then you could use a wildcard CN field descriptor in 
your certificate:  *.mydomain.com

If we are talking about a multidomain certificate, then you would have the 
main domain name in CN and add all the remaining domain names in the 
subjectAltName field.

For example:

[req]
req_extensions = v3_req

[ v3_req ]

# Extensions to add to a certificate request
[snip...]

subjectAltName = @alt_names

[alt_names]
DNS.1 = mydomain.com
DNS.2 = mydomain.net
DNS.3 = www.mydomain.com
DNS.4 = mx.sub.mydomain.com
DNS.5 = mx.someotherdomain.com
IP.1 = 123.456.78.9
IP.2 = 987.654.32.1

You could specify the same on the CLI when you are generating the self signed 
certificate.


> How do I deploy some sort of central infrastructure all clients on the
> LAN and anywhere on the world will automatically use to do the simple
> thing of adding an exception (or whatever is required for that) so that
> seamonkey and relatives can be used to access email?
> 
> That's letting aside that it's ridiculous to deploy such an
> infrastructure when the same thing could be achieved by the user
> clicking a button once to add an exception, as it used to be.

This I think is primarily a problem of the latest version of SeaMonkey.  I 
suspect they have inadvertently added a regression bug.


> Seriously?  The result is currently a version freeze; the alternative is
> using unencrypted connections.  After some time, the version freeze
> cannot be kept up.  Since there are no alternative MUAs, we can only go
> back to unencrypted connections when that happens.  And that's something
> I don't even want to do on the LAN.
> 
> 
> Well, I've made a bug report about this:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1202128

Also have a look at this bug, in case it is related:

https://bugzilla.mozilla.org/show_bug.cgi?id=1036338

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] broken seamonkey :(

[Fernando Rodriguez]

On Saturday, September 05, 2015 6:09:36 PM Mick wrote:
> On Saturday 05 Sep 2015 14:06:27 lee wrote:
> > Fernando Rodriguez <frodriguez.developer@outlook.com> writes:
> > > On Saturday, September 05, 2015 1:05:06 AM lee wrote:
> > >> In this case, I happen to have full physical access to the server and
> > >> thus to the certificate stored on it.  This is not the case for, let's
> > >> say, an employee checking his work-email from home whom I might give 
the
> > >> login-data on the phone and instruct to add an exception when the 
dialog
> > >> to do so pops up when they are trying to connect.
> > > 
> > > As a workaround you can create your own CA cert. I tested with a windows
> > > self- signed cert (I guess the correct term is self-issued) and the
> > > openssl command will show two certs. The second is the CA.
> > > 
> > > http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certifica
> > > te-authority/
> > 
> > They're saying:
> > 
> > 
> > "Whatever you see in the address field in your browser when you go to
> > your device must be what you put under common name, even if it’s an IP
> > address.  [...]  If it doesn’t match, even a properly signed certificate
> > will not validate correctly and you’ll get the “cannot verify
> > authenticity” error."
> > 
> > 
> > What's the solution for a server which can be reached by different fqdns
> > and IPs?  What if the fqdns and IPs it can be reached by change over the
> > lifetime of the certificates?
> 
> If we are talking about changing subdomains, e.g. mailserver1.mydomain.com 
and 
> mailserver2.mydomain.com then you could use a wildcard CN field descriptor in 
> your certificate:  *.mydomain.com
> 
> If we are talking about a multidomain certificate, then you would have the 
> main domain name in CN and add all the remaining domain names in the 
> subjectAltName field.
> 
> For example:
> 
> [req]
> req_extensions = v3_req
> 
> [ v3_req ]
> 
> # Extensions to add to a certificate request
> [snip...]
> 
> subjectAltName = @alt_names
> 
> [alt_names]
> DNS.1 = mydomain.com
> DNS.2 = mydomain.net
> DNS.3 = www.mydomain.com
> DNS.4 = mx.sub.mydomain.com
> DNS.5 = mx.someotherdomain.com
> IP.1 = 123.456.78.9
> IP.2 = 987.654.32.1
> 
> You could specify the same on the CLI when you are generating the self 
signed 
> certificate.
> 
> 
> > How do I deploy some sort of central infrastructure all clients on the
> > LAN and anywhere on the world will automatically use to do the simple
> > thing of adding an exception (or whatever is required for that) so that
> > seamonkey and relatives can be used to access email?
> > 
> > That's letting aside that it's ridiculous to deploy such an
> > infrastructure when the same thing could be achieved by the user
> > clicking a button once to add an exception, as it used to be.
> 
> This I think is primarily a problem of the latest version of SeaMonkey.  I 
> suspect they have inadvertently added a regression bug.
> 
> 
> > Seriously?  The result is currently a version freeze; the alternative is
> > using unencrypted connections.  After some time, the version freeze
> > cannot be kept up.  Since there are no alternative MUAs, we can only go
> > back to unencrypted connections when that happens.  And that's something
> > I don't even want to do on the LAN.
> > 
> > 
> > Well, I've made a bug report about this:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1202128
> 
> Also have a look at this bug, in case it is related:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1036338

Wildcards  should do it. The browser will give you a warning but you don't 
care since all you want is encryption and your users already trust you.

The only thing that matters about that article is that you'll be signing your 
certificate with the CA ones so you get two certificates when you run the 
openssl command, the last one is the CA certificate. If you, or your users add 
trust to that one, anything you sign with it will be trusted.

I only tried it with a windows server issued certificate which does all that by 
default.

Since it lets you open the exception dialog but just hangs when downloading 
the certificate I wonder if it has something to do with your OCSP settings. 
Check that they match mine:

security.OCSP.GET.enabled false
security.OCSP.enabled 1
security.OCSP.require false

everything else is true.


-- 
Fernando Rodriguez

Re: [gentoo-user] broken seamonkey :(

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 5361 bytes --]

On Saturday 05 Sep 2015 22:40:09 Fernando Rodriguez wrote:
> On Saturday, September 05, 2015 6:09:36 PM Mick wrote:
> > On Saturday 05 Sep 2015 14:06:27 lee wrote:
> > > Fernando Rodriguez <frodriguez.developer@outlook.com> writes:
> > > > On Saturday, September 05, 2015 1:05:06 AM lee wrote:
> > > >> In this case, I happen to have full physical access to the server
> > > >> and thus to the certificate stored on it.  This is not the case
> > > >> for, let's say, an employee checking his work-email from home whom
> > > >> I might give
> 
> the
> 
> > > >> login-data on the phone and instruct to add an exception when the
> 
> dialog
> 
> > > >> to do so pops up when they are trying to connect.
> > > > 
> > > > As a workaround you can create your own CA cert. I tested with a
> > > > windows self- signed cert (I guess the correct term is self-issued)
> > > > and the openssl command will show two certs. The second is the CA.
> > > > 
> > > > http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certi
> > > > fica te-authority/
> > > 
> > > They're saying:
> > > 
> > > 
> > > "Whatever you see in the address field in your browser when you go to
> > > your device must be what you put under common name, even if it’s an IP
> > > address.  [...]  If it doesn’t match, even a properly signed
> > > certificate will not validate correctly and you’ll get the “cannot
> > > verify
> > > authenticity” error."
> > > 
> > > 
> > > What's the solution for a server which can be reached by different
> > > fqdns and IPs?  What if the fqdns and IPs it can be reached by change
> > > over the lifetime of the certificates?
> > 
> > If we are talking about changing subdomains, e.g.
> > mailserver1.mydomain.com
> 
> and
> 
> > mailserver2.mydomain.com then you could use a wildcard CN field
> > descriptor in your certificate:  *.mydomain.com
> > 
> > If we are talking about a multidomain certificate, then you would have
> > the main domain name in CN and add all the remaining domain names in the
> > subjectAltName field.
> > 
> > For example:
> > 
> > [req]
> > req_extensions = v3_req
> > 
> > [ v3_req ]
> > 
> > # Extensions to add to a certificate request
> > [snip...]
> > 
> > subjectAltName = @alt_names
> > 
> > [alt_names]
> > DNS.1 = mydomain.com
> > DNS.2 = mydomain.net
> > DNS.3 = www.mydomain.com
> > DNS.4 = mx.sub.mydomain.com
> > DNS.5 = mx.someotherdomain.com
> > IP.1 = 123.456.78.9
> > IP.2 = 987.654.32.1
> > 
> > You could specify the same on the CLI when you are generating the self
> 
> signed
> 
> > certificate.
> > 
> > > How do I deploy some sort of central infrastructure all clients on the
> > > LAN and anywhere on the world will automatically use to do the simple
> > > thing of adding an exception (or whatever is required for that) so that
> > > seamonkey and relatives can be used to access email?
> > > 
> > > That's letting aside that it's ridiculous to deploy such an
> > > infrastructure when the same thing could be achieved by the user
> > > clicking a button once to add an exception, as it used to be.
> > 
> > This I think is primarily a problem of the latest version of SeaMonkey. 
> > I suspect they have inadvertently added a regression bug.
> > 
> > > Seriously?  The result is currently a version freeze; the alternative
> > > is using unencrypted connections.  After some time, the version freeze
> > > cannot be kept up.  Since there are no alternative MUAs, we can only
> > > go back to unencrypted connections when that happens.  And that's
> > > something I don't even want to do on the LAN.
> > > 
> > > 
> > > Well, I've made a bug report about this:
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1202128
> > 
> > Also have a look at this bug, in case it is related:
> > 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1036338
> 
> Wildcards  should do it. The browser will give you a warning but you don't
> care since all you want is encryption and your users already trust you.
> 
> The only thing that matters about that article is that you'll be signing
> your certificate with the CA ones so you get two certificates when you run
> the openssl command, the last one is the CA certificate. If you, or your
> users add trust to that one, anything you sign with it will be trusted.
> 
> I only tried it with a windows server issued certificate which does all
> that by default.
> 
> Since it lets you open the exception dialog but just hangs when downloading
> the certificate I wonder if it has something to do with your OCSP settings.
> Check that they match mine:
> 
> security.OCSP.GET.enabled false
> security.OCSP.enabled 1
> security.OCSP.require false
> 
> everything else is true.

Some reports mention a couple of workarounds which may solve this problem:

1. Remove your certificate from *any* tabs that may have been saved in.  Check 
that it is no longer stored in any tab.

Then try to reload it in the Authorities tab and see if it will allow you to 
set up an exception.

2. I think you mentioned that you tried a fresh profile, but just in case:  
Make a back up of your Mozilla Profile.  Go to Help/Troubleshooting and select 
Refresh Firefox (or the equivalent for the SeaMonkey GUI).

HTH.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] broken seamonkey :(

[lee]

Mick <michaelkintzios@gmail.com> writes:

> On Saturday 05 Sep 2015 22:40:09 Fernando Rodriguez wrote:
>> 
>> Since it lets you open the exception dialog but just hangs when downloading
>> the certificate I wonder if it has something to do with your OCSP settings.
>> Check that they match mine:
>> 
>> security.OCSP.GET.enabled false
>> security.OCSP.enabled 1
>> security.OCSP.require false
>> 
>> everything else is true.
>
> Some reports mention a couple of workarounds which may solve this problem:
>
> 1. Remove your certificate from *any* tabs that may have been saved in.  Check 
> that it is no longer stored in any tab.
>
> Then try to reload it in the Authorities tab and see if it will allow you to 
> set up an exception.
>
> 2. I think you mentioned that you tried a fresh profile, but just in case:  
> Make a back up of your Mozilla Profile.  Go to Help/Troubleshooting and select 
> Refresh Firefox (or the equivalent for the SeaMonkey GUI).

I moved ~/.mozilla out of the way, imported the certificate under
authorities, gave it all trust, and I'm getting exactly the same as
before when trying to connect:  The dialog to add an exception comes up,
with the buttons to add one disabled, and clicking on "Get Certificate"
does nothing.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] broken seamonkey :(

[lee]

Fernando Rodriguez <frodriguez.developer@outlook.com> writes:

> On Saturday, September 05, 2015 6:09:36 PM Mick wrote:
>> On Saturday 05 Sep 2015 14:06:27 lee wrote:
>> > Fernando Rodriguez <frodriguez.developer@outlook.com> writes:
>> > > On Saturday, September 05, 2015 1:05:06 AM lee wrote:
>> > >> In this case, I happen to have full physical access to the server and
>> > >> thus to the certificate stored on it.  This is not the case for, let's
>> > >> say, an employee checking his work-email from home whom I might give 
> the
>> > >> login-data on the phone and instruct to add an exception when the 
> dialog
>> > >> to do so pops up when they are trying to connect.
>> > > 
>> > > As a workaround you can create your own CA cert. I tested with a windows
>> > > self- signed cert (I guess the correct term is self-issued) and the
>> > > openssl command will show two certs. The second is the CA.
>> > > 
>> > > http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certifica
>> > > te-authority/
>> > 
>> > They're saying:
>> > 
>> > 
>> > "Whatever you see in the address field in your browser when you go to
>> > your device must be what you put under common name, even if it’s an IP
>> > address.  [...]  If it doesn’t match, even a properly signed certificate
>> > will not validate correctly and you’ll get the “cannot verify
>> > authenticity” error."
>> > 
>> > 
>> > What's the solution for a server which can be reached by different fqdns
>> > and IPs?  What if the fqdns and IPs it can be reached by change over the
>> > lifetime of the certificates?
>> 
> [...]
>
> Wildcards  should do it. The browser will give you a warning but you don't 
> care since all you want is encryption and your users already trust you.

True --- and the problem will be back again when seamonkey etc. decide
not to accept certificates with wildcards anymore.

> The only thing that matters about that article is that you'll be signing your 
> certificate with the CA ones so you get two certificates when you run the 
> openssl command, the last one is the CA certificate. If you, or your users add 
> trust to that one, anything you sign with it will be trusted.
>
> I only tried it with a windows server issued certificate which does all that by 
> default.

Changing the key would be a last resort.

If I do that, should I use a SHA-3 key?  Would that work, or is SHA-3
too new?

> Since it lets you open the exception dialog but just hangs when downloading 
> the certificate I wonder if it has something to do with your OCSP settings. 
> Check that they match mine:
>
> security.OCSP.GET.enabled false
> security.OCSP.enabled 1
> security.OCSP.require false
>
> everything else is true.

I checked, and we have the same settings.  It doesn't really hang, it
does nothing when I try to get the certificate.  Does it do something
when you try?


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] broken seamonkey :(

[Fernando Rodriguez]

On Sunday, September 06, 2015 3:03:12 PM lee wrote:
> Fernando Rodriguez <frodriguez.developer@outlook.com> writes:
> 
> > On Saturday, September 05, 2015 6:09:36 PM Mick wrote:
> >> On Saturday 05 Sep 2015 14:06:27 lee wrote:
> >> > Fernando Rodriguez <frodriguez.developer@outlook.com> writes:
> >> > > On Saturday, September 05, 2015 1:05:06 AM lee wrote:
> >> > >> In this case, I happen to have full physical access to the server 
and
> >> > >> thus to the certificate stored on it.  This is not the case for, 
let's
> >> > >> say, an employee checking his work-email from home whom I might give 
> > the
> >> > >> login-data on the phone and instruct to add an exception when the 
> > dialog
> >> > >> to do so pops up when they are trying to connect.
> >> > > 
> >> > > As a workaround you can create your own CA cert. I tested with a 
windows
> >> > > self- signed cert (I guess the correct term is self-issued) and the
> >> > > openssl command will show two certs. The second is the CA.
> >> > > 
> >> > > http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certifica
> >> > > te-authority/
> >> > 
> >> > They're saying:
> >> > 
> >> > 
> >> > "Whatever you see in the address field in your browser when you go to
> >> > your device must be what you put under common name, even if it’s an IP
> >> > address.  [...]  If it doesn’t match, even a properly signed certificate
> >> > will not validate correctly and you’ll get the “cannot verify
> >> > authenticity” error."
> >> > 
> >> > 
> >> > What's the solution for a server which can be reached by different fqdns
> >> > and IPs?  What if the fqdns and IPs it can be reached by change over 
the
> >> > lifetime of the certificates?
> >> 
> > [...]
> >
> > Wildcards  should do it. The browser will give you a warning but you don't 
> > care since all you want is encryption and your users already trust you.
> 
> True --- and the problem will be back again when seamonkey etc. decide
> not to accept certificates with wildcards anymore.
> 
> > The only thing that matters about that article is that you'll be signing 
your 
> > certificate with the CA ones so you get two certificates when you run the 
> > openssl command, the last one is the CA certificate. If you, or your users 
add 
> > trust to that one, anything you sign with it will be trusted.
> >
> > I only tried it with a windows server issued certificate which does all 
that by 
> > default.
> 
> Changing the key would be a last resort.
> 
> If I do that, should I use a SHA-3 key?  Would that work, or is SHA-3
> too new?

You don't need to change the private key, you'll just have another CA cert and 
private key that you can use to sign your existing certificate (and generate a 
signed one). I suppose you may even be able to use the same key for both.

> > Since it lets you open the exception dialog but just hangs when 
downloading 
> > the certificate I wonder if it has something to do with your OCSP settings. 
> > Check that they match mine:
> >
> > security.OCSP.GET.enabled false
> > security.OCSP.enabled 1
> > security.OCSP.require false
> >
> > everything else is true.
> 
> I checked, and we have the same settings.  It doesn't really hang, it
> does nothing when I try to get the certificate.  Does it do something
> when you try?

It downloads the cert as expected. When I do it from the error page I don't 
even have to do that because it's already downloaded. What does it says under 
"Technical Details" on the error page?

-- 
Fernando Rodriguez

Re: [gentoo-user] broken seamonkey :(

[lee]

Mick <michaelkintzios@gmail.com> writes:

> On Saturday 05 Sep 2015 14:06:27 lee wrote:
>> Fernando Rodriguez <frodriguez.developer@outlook.com> writes:
>> > On Saturday, September 05, 2015 1:05:06 AM lee wrote:
>> >> In this case, I happen to have full physical access to the server and
>> >> thus to the certificate stored on it.  This is not the case for, let's
>> >> say, an employee checking his work-email from home whom I might give the
>> >> login-data on the phone and instruct to add an exception when the dialog
>> >> to do so pops up when they are trying to connect.
>> > 
>> > As a workaround you can create your own CA cert. I tested with a windows
>> > self- signed cert (I guess the correct term is self-issued) and the
>> > openssl command will show two certs. The second is the CA.
>> > 
>> > http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certifica
>> > te-authority/
>> 
>> They're saying:
>> 
>> 
>> "Whatever you see in the address field in your browser when you go to
>> your device must be what you put under common name, even if it’s an IP
>> address.  [...]  If it doesn’t match, even a properly signed certificate
>> will not validate correctly and you’ll get the “cannot verify
>> authenticity” error."
>> 
>> 
>> What's the solution for a server which can be reached by different fqdns
>> and IPs?  What if the fqdns and IPs it can be reached by change over the
>> lifetime of the certificates?
>
> If we are talking about changing subdomains, e.g. mailserver1.mydomain.com and 
> mailserver2.mydomain.com then you could use a wildcard CN field descriptor in 
> your certificate:  *.mydomain.com

just different fqdns and IPs with which the server can be reached during
the lifetime of the certificate (which is only 10 years)

Can you foresee all possible fqdns and IPs it might have in the next 10
years?

I think it would be retarded to bind a certificate to a fqdn or IP. Both
can change at any time.  It's the certificate that counts and which can
be verified by a fingerprint before accepting it.  The host name and IP
are entirely irrelevant for this.  In some cases, you can even say that
the certificate is for an organization, not for a particular host or
device (operated by or being operated on behalf of the organization).


Or think of gpg: Binding a certificate to fqdn/IP would be like binding
my gpg public key to the place (like my postal address) I am at so that
I can decrypt something only when I happen to be at the right
place. Then give me an option to add multiple places to my pubkey when
creating it, and as soon as I'm at another place about which I haven't
foreseen that I might be there some time, I will have a problem.  For
all I know, I could be travelling in a car or a train or an air plane.

It's impractical.  Change is a constant.

> If we are talking about a multidomain certificate, then you would have the 
> main domain name in CN and add all the remaining domain names in the 
> subjectAltName field.
>
> For example:
>
> [req]
> req_extensions = v3_req
>
> [ v3_req ]
>
> # Extensions to add to a certificate request
> [snip...]
>
> subjectAltName = @alt_names
>
> [alt_names]
> DNS.1 = mydomain.com
> DNS.2 = mydomain.net
> DNS.3 = www.mydomain.com
> DNS.4 = mx.sub.mydomain.com
> DNS.5 = mx.someotherdomain.com
> IP.1 = 123.456.78.9
> IP.2 = 987.654.32.1
>
> You could specify the same on the CLI when you are generating the self signed 
> certificate.

At least that's possible.  How would I add that without changing the
existing certificate?  I don't want to irritate the users, don't want to
have the phone calls about it and don't want trouble with the odd client
which happens to have been updated and refuses to accept the certificate
...

See what I mean?  It's impractical.

>> How do I deploy some sort of central infrastructure all clients on the
>> LAN and anywhere on the world will automatically use to do the simple
>> thing of adding an exception (or whatever is required for that) so that
>> seamonkey and relatives can be used to access email?
>> 
>> That's letting aside that it's ridiculous to deploy such an
>> infrastructure when the same thing could be achieved by the user
>> clicking a button once to add an exception, as it used to be.
>
> This I think is primarily a problem of the latest version of SeaMonkey.  I 
> suspect they have inadvertently added a regression bug.
>
>
>> Seriously?  The result is currently a version freeze; the alternative is
>> using unencrypted connections.  After some time, the version freeze
>> cannot be kept up.  Since there are no alternative MUAs, we can only go
>> back to unencrypted connections when that happens.  And that's something
>> I don't even want to do on the LAN.
>> 
>> 
>> Well, I've made a bug report about this:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1202128
>
> Also have a look at this bug, in case it is related:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1036338

I really can't tell.  It seems different in that even certificates that
were already used don't work anymore, which isn't the case here.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] broken seamonkey :(

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 4718 bytes --]

On Sunday 06 Sep 2015 03:45:26 lee wrote:
> Mick <michaelkintzios@gmail.com> writes:
> > On Saturday 05 Sep 2015 14:06:27 lee wrote:

> >> What's the solution for a server which can be reached by different fqdns
> >> and IPs?  What if the fqdns and IPs it can be reached by change over the
> >> lifetime of the certificates?
> > 
> > If we are talking about changing subdomains, e.g.
> > mailserver1.mydomain.com and mailserver2.mydomain.com then you could use
> > a wildcard CN field descriptor in your certificate:  *.mydomain.com
> 
> just different fqdns and IPs with which the server can be reached during
> the lifetime of the certificate (which is only 10 years)
> 
> Can you foresee all possible fqdns and IPs it might have in the next 10
> years?

OK, 10 years is rather long for a common certificate.  In this case you should 
consider setting up your own CA key and CA certificate, with which you sign 
the server certificates.  Server certificates can expire and/or be revoked, 
you can update and publish a CRL, but the CA certificate will remain valid for 
10 years.

As long as the new server certificate is signed by the same CA certificate, 
the clients should not mind provided:

1. The client has accepted the CA certificate in its Authorities store and set 
up an exception to mark it as trusted.
2. The CN of the new certificate contains the URI that the client is trying to 
connect to.
3. The expiry date has not arrived yet.
4. The CRL does not contain the certificate (yet).


> I think it would be retarded to bind a certificate to a fqdn or IP. Both
> can change at any time.  It's the certificate that counts and which can
> be verified by a fingerprint before accepting it.  The host name and IP
> are entirely irrelevant for this.  In some cases, you can even say that
> the certificate is for an organization, not for a particular host or
> device (operated by or being operated on behalf of the organization).

When you change the domain or IP address on a server you typically change its 
certificate to reflect this too.  You do not need to change the CA 
certificate.

If you change the contents of the certificate then the fingerprint will change 
too.  Certificate verification tests include more than just the fingerprint.


> Or think of gpg: Binding a certificate to fqdn/IP would be like binding
> my gpg public key to the place (like my postal address) I am at so that
> I can decrypt something only when I happen to be at the right
> place. Then give me an option to add multiple places to my pubkey when
> creating it, and as soon as I'm at another place about which I haven't
> foreseen that I might be there some time, I will have a problem.  For
> all I know, I could be travelling in a car or a train or an air plane.
> 
> It's impractical.  Change is a constant.

Sure, but (although you could) gpg is not usually used to secure the 
connection to a server.  A server's identity is interlinked with its domain 
name, or IP address.  The identity for gpg is linked to the email address of 
its owner.  You wouldn't sign/encrypt your work's email with the gpg key for 
your private email address.


> > If we are talking about a multidomain certificate, then you would have
> > the main domain name in CN and add all the remaining domain names in the
> > subjectAltName field.
> > 
> > For example:
> > 
> > [req]
> > req_extensions = v3_req
> > 
> > [ v3_req ]
> > 
> > # Extensions to add to a certificate request
> > [snip...]
> > 
> > subjectAltName = @alt_names
> > 
> > [alt_names]
> > DNS.1 = mydomain.com
> > DNS.2 = mydomain.net
> > DNS.3 = www.mydomain.com
> > DNS.4 = mx.sub.mydomain.com
> > DNS.5 = mx.someotherdomain.com
> > IP.1 = 123.456.78.9
> > IP.2 = 987.654.32.1
> > 
> > You could specify the same on the CLI when you are generating the self
> > signed certificate.
> 
> At least that's possible.  How would I add that without changing the
> existing certificate?  I don't want to irritate the users, don't want to
> have the phone calls about it and don't want trouble with the odd client
> which happens to have been updated and refuses to accept the certificate
> ...
> 
> See what I mean?  It's impractical.

Yes. It could be impractical at this stage, because the architecture of your 
PKI has to change.

However, you can treat your existent self-signed certificate as a CA and use 
it to sign other certificates which contain different IP addresses, fqdns, 
etc. depending on the server(s) in question.

If your clients have accepted your self-signed certificate as a CA, then it 
should not cause a problem.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] broken seamonkey :(

[lee]

Mick <michaelkintzios@gmail.com> writes:

> On Sunday 06 Sep 2015 03:45:26 lee wrote:
>> Mick <michaelkintzios@gmail.com> writes:
>> > On Saturday 05 Sep 2015 14:06:27 lee wrote:
>
>> >> What's the solution for a server which can be reached by different fqdns
>> >> and IPs?  What if the fqdns and IPs it can be reached by change over the
>> >> lifetime of the certificates?
>> > 
>> > If we are talking about changing subdomains, e.g.
>> > mailserver1.mydomain.com and mailserver2.mydomain.com then you could use
>> > a wildcard CN field descriptor in your certificate:  *.mydomain.com
>> 
>> just different fqdns and IPs with which the server can be reached during
>> the lifetime of the certificate (which is only 10 years)
>> 
>> Can you foresee all possible fqdns and IPs it might have in the next 10
>> years?
>
> OK, 10 years is rather long for a common certificate.  In this case you should 
> consider setting up your own CA key and CA certificate, with which you sign 
> the server certificates.  Server certificates can expire and/or be revoked, 
> you can update and publish a CRL, but the CA certificate will remain valid for 
> 10 years.

I made it 10 years because you have to set a duration, and I didn't want
to be bothered with certificates expiring.  But I understand that I've
been doing it kinda wrong because it would have been better to make a CA
certificate which could be valid for a long time and sign certificates
with it which don't last that long.

Can I somehow deploy some sort of centralized infrastructure for clients
to automatically get the CA certificates from?  Otherwise, I would need
to import the CA certificate for every user manually.

> [...]
>
>> I think it would be retarded to bind a certificate to a fqdn or IP. Both
>> can change at any time.  It's the certificate that counts and which can
> [...]
>
> Sure, but (although you could) gpg is not usually used to secure the 
> connection to a server.  A server's identity is interlinked with its domain 
> name, or IP address.  The identity for gpg is linked to the email address of 
> its owner.  You wouldn't sign/encrypt your work's email with the gpg key for 
> your private email address.

With gpg, the linkage to an email address was introduced a long time ago
to make it easy to determine from an email address which key to use.
Back then, people usually did have no more than one email address,
perhaps another one at their work place, and most people didn't have any
email addresses at all.

That has changed.  However, even back then, the email address wasn't
used to identify a person.  You could only know that, with a great deal
of likelyness, an email --- sent from whatever email address --- was
sent by a particular person when it was signed or encrypted with the key
you definitely knew was that particular person's key.

That has *not* changed.  The same principle applies to certificates.

So what sense does it make for a certificate to be linked to an FQDN or
IP?  None of those necessarily identify a particular server.  If they
did, the only purpose of certificates would be to assist encryption, and
they wouldn't have anything to do with identification. --- You're using
gmail (which I won't because of privacy concerns):  Can you be sure that
you connect to the same server every time you receive or send your
emails?  You probably don't.

The underlying idea is trust.  If you trust a CA --- and I don't see any
particular reason to trust any of the CAs seamonkey knows by default and
most, if not all of which, I've never even heard about --- a certificate
signed by it is accepted without asking you.

Is that good or bad?  Back then, when I used gpg, I had my key signed by
people I met personally and signed theirs.  We would know by the fact
that the key was used, not by any particular email address.

So the identity for gpg is *not* linked to the email address of its
owner. Nobody prevents you from encrypting or signing an email with your
key and sending it from an arbitrary email address.  Recipients may only
conclude that it was you who sent the email by verifying that your key
was used, and first they have to trust that this key is actually yours.
You may need to explicitly specify the key-ID or an email address to
tell gpg which key to use when you do that.

Same goes for certificates, and there's no point in linking them to
FQDNs/IPs.  If they are linked for the practical reason to figure out
which certificate to use, like gpg can use an email address to figure
out which key to use, then I'd say that a better way needs to be found
to do that.  Similar to a key-ID specific to a key, certificates could
have a certificate-ID --- perhaps they already do.

>> > If we are talking about a multidomain certificate, then you would have
>> > the main domain name in CN and add all the remaining domain names in the
>> > subjectAltName field.
>> > 
>> > For example:
>> > 
>> > [req]
>> > req_extensions = v3_req
>> > 
>> > [ v3_req ]
>> > 
>> > # Extensions to add to a certificate request
>> > [snip...]
>> > 
>> > subjectAltName = @alt_names
>> > 
>> > [alt_names]
>> > DNS.1 = mydomain.com
>> > DNS.2 = mydomain.net
>> > DNS.3 = www.mydomain.com
>> > DNS.4 = mx.sub.mydomain.com
>> > DNS.5 = mx.someotherdomain.com
>> > IP.1 = 123.456.78.9
>> > IP.2 = 987.654.32.1
>> > 
>> > You could specify the same on the CLI when you are generating the self
>> > signed certificate.
>> 
>> At least that's possible.  How would I add that without changing the
>> existing certificate?  I don't want to irritate the users, don't want to
>> have the phone calls about it and don't want trouble with the odd client
>> which happens to have been updated and refuses to accept the certificate
>> ...
>> 
>> See what I mean?  It's impractical.
>
> Yes. It could be impractical at this stage, because the architecture of your 
> PKI has to change.
>
> However, you can treat your existent self-signed certificate as a CA and use 
> it to sign other certificates which contain different IP addresses, fqdns, 
> etc. depending on the server(s) in question.
>
> If your clients have accepted your self-signed certificate as a CA, then it 
> should not cause a problem.

When I look at one of the CA certificates seamonkey shows me, I don't
see any specific FQDN or IP involved.  Am I to understand that a CA
certificate is like what I kinda wanted in the first place, i. e. something
like a certificate which identifies an organization (rather than a
device operated by the organization)?  And that the CA certificate can
be used (by the organization) to, well, certify that a particular device
it operates is operated by the organisation by creating a certificate
for the device and signing it with the CA certificate?

If that is so, then why should I need or use one certificate for each
device --- or for each service?  I'm certifying myself that this is the
particular organisation and that everything is fine, one way or
another. So far, the true and only purpose of these certificates is to
assist encryption.  Unless I am able to give users, in a secure way,
some means of verifying that a certificate they accept is actually from
the organization, the certificates cannot be used for identification
anyway.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

[gentoo-user] SOLVED: broken seamonkey :(

[lee]

lee <lee@yagibdah.de> writes:

> Well, I've made a bug report about this: https://bugzilla.mozilla.org/show_bug.cgi?id=1202128

They suggested to try with seamonkey 2.35.  I tried and found that 2.35
(and 2.38 beta) work fine.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.