You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Pierre Fourès <pi...@gmail.com> on 2019/07/19 11:40:52 UTC
Is Permanently Accept SSL Certificate gone in 1.10.4 ?
Hi all,
I have a script accessing an old svn server whom SSL certificate have
expired a long time ago. Up to now, I was permanently accepting the
certificate on the first run of the script and then everything was
sailling smooth. I reinstalled a couple of months ago a new box where
this script was intented to run and the (p)ermanently option seems not
provided anymore.
Thankfully, I still have the "old" running box to double-check, and
the (p)ermanently option is still present. Both boxes are Debian
Buster (but was installed as unstable, before the official release).
The (p)ermanently option was also present in svn on previous versions
of Debian.
I can notice that the versions of svn changed between my old and new
box from 1.10.2 to 1.10.4. Nonetheless, I gave a look at the
change-log [1] and it doesn't seem specified this option has been
removed. I also gave a look on openssl version and it went upgraded
from 1.1.0h to 1.1.1b, but I have no clue to evaluate if the removal
of the (p)ermanently option is linked or not the openssl upgrade.
If some of you have an hint and an half to explain how and why this
option disapeared, that would be really nice. I wonder if it was meant
or not, to see where I'm headed.
More over, I would really appreciate if someone could share a solution
to still permanently accept the certificate on the new box, as for
now, I can't use this box and the old one should soon be
decommissioned.
Best Regards,
Pierre
[1] https://svn.apache.org/repos/asf/subversion/tags/1.10.4/CHANGES
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
Posted by Pierre Fourès <pi...@gmail.com>.
Le sam. 20 juil. 2019 à 16:55, Nico Kadel-Garcia <nk...@gmail.com> a écrit :
>
> On Fri, Jul 19, 2019 at 7:41 AM Pierre Fourès <pi...@gmail.com> wrote:
> >
> > Hi all,
> >
> > I have a script accessing an old svn server whom SSL certificate have
> > expired a long time ago. Up to now, I was permanently accepting the
> > certificate on the first run of the script and then everything was
> > sailling smooth. I reinstalled a couple of months ago a new box where
> > this script was intented to run and the (p)ermanently option seems not
> > provided anymore.
>
> Negotiating certificate trust can be fun. Can you sidestep the whole
> issue by switching to svn+sh? Or get new, signed certificates?
>
> > Thankfully, I still have the "old" running box to double-check, and
> > the (p)ermanently option is still present. Both boxes are Debian
> > Buster (but was installed as unstable, before the official release).
> > The (p)ermanently option was also present in svn on previous versions
> > of Debian.
> >
> > I can notice that the versions of svn changed between my old and new
> > box from 1.10.2 to 1.10.4. Nonetheless, I gave a look at the
> > change-log [1] and it doesn't seem specified this option has been
> > removed. I also gave a look on openssl version and it went upgraded
> > from 1.1.0h to 1.1.1b, but I have no clue to evaluate if the removal
> > of the (p)ermanently option is linked or not the openssl upgrade.
> >
> > If some of you have an hint and an half to explain how and why this
> > option disapeared, that would be really nice. I wonder if it was meant
> > or not, to see where I'm headed.
> >
> > More over, I would really appreciate if someone could share a solution
> > to still permanently accept the certificate on the new box, as for
> > now, I can't use this box and the old one should soon be
> > decommissioned.
>
> Stefan has correctly pointed out ways to get your client, at run-time,
> to accept failed certificates. But what is stopping you from replacing
> the certificate?
It's on the todo-list for quite a long time but never find it ways to
get to prime time. We decided to migrate this server to a new
infrastructure and it will benefits from automatically renewed Let's
Encrypt certificates. That will eventually address all points. But as
things works well and wouldn't add significant benefits, we didn't
haven't scheduled the operation so far.
The server is running smooth and used only for internal use, so by the
time Let's Encrypt wasn't here, we didn't felt to spent some money on
buying a certificate from a trusted authority. As self certificates
(rightly) reported an error, we already had to « accept permanently »
the certificate when we was re-configuring a new client instance. Then
the certificate expired. This added one line in the warnings, but
didn't really change a thing for us, so we didn't felt the urge to
renew the certificate. We knew which it was and we trusted it.
More over, the encountered problem seems that the self-signed
certificate switched from being reported as "not trusted" to "unknown
error". The cause then seems rooted in the self certification, so I'm
not sure issuing a new self-signed certificate would solve the problem
?
Best Regards,
Pierre.
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Fri, Jul 19, 2019 at 7:41 AM Pierre Fourès <pi...@gmail.com> wrote:
>
> Hi all,
>
> I have a script accessing an old svn server whom SSL certificate have
> expired a long time ago. Up to now, I was permanently accepting the
> certificate on the first run of the script and then everything was
> sailling smooth. I reinstalled a couple of months ago a new box where
> this script was intented to run and the (p)ermanently option seems not
> provided anymore.
Negotiating certificate trust can be fun. Can you sidestep the whole
issue by switching to svn+sh? Or get new, signed certificates?
> Thankfully, I still have the "old" running box to double-check, and
> the (p)ermanently option is still present. Both boxes are Debian
> Buster (but was installed as unstable, before the official release).
> The (p)ermanently option was also present in svn on previous versions
> of Debian.
>
> I can notice that the versions of svn changed between my old and new
> box from 1.10.2 to 1.10.4. Nonetheless, I gave a look at the
> change-log [1] and it doesn't seem specified this option has been
> removed. I also gave a look on openssl version and it went upgraded
> from 1.1.0h to 1.1.1b, but I have no clue to evaluate if the removal
> of the (p)ermanently option is linked or not the openssl upgrade.
>
> If some of you have an hint and an half to explain how and why this
> option disapeared, that would be really nice. I wonder if it was meant
> or not, to see where I'm headed.
>
> More over, I would really appreciate if someone could share a solution
> to still permanently accept the certificate on the new box, as for
> now, I can't use this box and the old one should soon be
> decommissioned.
Stefan has correctly pointed out ways to get your client, at run-time,
to accept failed certificates. But what is stopping you from replacing
the certificate?
> Best Regards,
> Pierre
>
> [1] https://svn.apache.org/repos/asf/subversion/tags/1.10.4/CHANGES
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
Posted by Pierre Fourès <pi...@gmail.com>.
Le ven. 19 juil. 2019 à 20:44, Stefan Sperling <st...@elego.de> a écrit :
>
> On Fri, Jul 19, 2019 at 08:38:57PM +0200, Stefan Sperling wrote:
> > On Fri, Jul 19, 2019 at 01:40:52PM +0200, Pierre Fourčs wrote:
> > > Hi all,
> > >
> > > I have a script accessing an old svn server whom SSL certificate have
> > > expired a long time ago. Up to now, I was permanently accepting the
> > > certificate on the first run of the script and then everything was
> > > sailling smooth. I reinstalled a couple of months ago a new box where
> > > this script was intented to run and the (p)ermanently option seems not
> > > provided anymore.
> >
> > If you're scripting 'svn' you should be using the --non-interactive option.
> >
> > In which case your script can use the --trust-server-cert-failures
> > option to accept a cert in pre-determined failure cases.
> >
> > 'svn help update', for example, displays the following information
> > section about the --trust-server-cert-failures option:
> >
> > --trust-server-cert-failures ARG : with --non-interactive, accept SSL server
> > certificates with failures; ARG is comma-separated
> > list of 'unknown-ca' (Unknown Authority),
> > 'cn-mismatch' (Hostname mismatch), 'expired'
> > (Expired certificate), 'not-yet-valid' (Not yet
> > valid certificate) and 'other' (all other not
> > separately classified certificate errors).
> >
> > Once your script uses this option it should work out of the box against
> > your problematic server and there should be no need to save the cert.
>
> Follow-up regarding your actual question:
>
> It looks like the interactive prompt omits an option to save the cert
> if it sees a certificate failure of class 'other' from the above list.
> I am not sure why this decision was made but that's what the current
> code seems to do. So I suspect your SSL cert is failing for some reason
> other than unknown-ca, cn-mismatch, expired, not-yet-valid.
>
> Additionally, the ability to save a cert is also disabled if the
> --no-auth-cache option is used.
Hi,
Sorry for the delay and thanks a lot for the answers.
In fact, I did read about the non-interactive option but this question
[1] made me thought it wouldn't work. Having tried with
--trust-server-cert and got errors, I thought this was it. I didn't
saw there also was a --trust-server-cert-failures. I should have
better read the docs and see one can specify the nature of the error
to silent in order to consider the certificate as trustable !
I'm now able to proceed in non-interactive mode on the new instance
accessing the svn-server. Thanks. However, I couldn't find a way to
store the password. Of course, this is non-interactive mode.
Nonetheless, could it be a way to store the credentials ? If so this
would save me some time to tweak the scripts (and the need to export
credentials variables before running the scripts).
About the interactive prompt omitting the (p)ermanently save in case
of 'other' errors, you're right on spot, the class 'other' appeared as
reported errors in the instance running 1.10.4. I did a little more
investigation now that I better understand the inner functioning of
the certificate validation. What's really strange is that the error
nature changed from svn 1.10.2 to 1.10.4 while accessing the same svn
server, and thus, the same certificate. It's a self signed
certificate, and is rightly considered so in 1.10.2, as not trustable,
but is reported as an unknown certificate error in 1.10.4 (as the logs
attests). This would clearly explain why the (p)ermanently option
disappeared. Nonetheless, I wonder why « unknown authority error » is
now reported as « other error » in 1.10.4. Was it meant or is it a
regression ?
pierre@edtv-01-pierre:~$ svn --version
svn, version 1.10.2 (r1835932)
compiled Aug 4 2018, 16:28:03 on x86_64-pc-linux-gnu
pierre@edtv-01-pierre:~$ LANG=C svn co https://svn.---.fr/--- ---
Error validating server certificate for 'https://svn.---.fr:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
- The certificate hostname does not match.
- The certificate has expired.
(R)eject, accept (t)emporarily or accept (p)ermanently?
pierre@edtv-08-pierre:~$ svn --version
svn, version 1.10.4 (r1850624)
compiled Jan 23 2019, 03:41:34 on x86_64-pc-linux-gnu
pierre@edtv-08-pierre:~$ LANG=C svn co https://svn.---.fr/--- ---
Error validating server certificate for 'https://svn.---.fr:443':
- The certificate hostname does not match.
- The certificate has expired.
- The certificate has an unknown error.
Certificate information:
(R)eject or accept (t)emporarily?
Best Regards,
Pierre.
[1] https://unix.stackexchange.com/questions/318169/svn-automatically-accept-server-certificate
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
Posted by Branko Čibej <br...@apache.org>.
On Sat, 20 Jul 2019, 11:51 Stefan Sperling, <st...@elego.de> wrote:
>
> But as a user I find it infuriating when software I use contains
> artificial restrictions like this.
We recently disabled plaintext password storage (by default) in the build
configuration, making it effectively unavailable to users who don't build
from source. The rationale for that decision was the same as for not
permanently trusting certs with unknown failures.
We should assume our users know
> what they are doing. Subversion
is not a web browser.
>
I will refrain from spelling out the snide remark that immediately comes to
mind. :)
What we *should* do is use any platform APIs available for cert validation,
as I already mentioned on the other thread in my response to Evgeny's
commit. One might wish that OpenSSL through Serf took care of that, but
unfortunately it does not, so it's up to us. Given the growing popularity
of Let's Encrypt's server certs with 3 months validity, the potential for
user infuriation may be growing quite quickly.
-- Brane
>
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sat, Jul 20, 2019 at 2:54 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>
> Stefan Sperling wrote on Sat, 20 Jul 2019 09:51 +00:00:
> > But as a user I find it infuriating when software I use contains
> > artificial restrictions like this. We should assume our users know
> > what they are doing. Subversion is not a web browser.
>
> I'm not entirely sure I'm convinced by this logic. Let's take OpenSSH for example:
>
> [[[
> % ed .ssh/known_hosts
> g/^hermes/d
> s/^[^ ]*/hermes.apache.org/
> w
> q
> % ssh hermes.apache.org
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
> Someone could be eavesdropping on you right now (man-in-the-middle attack)!
> It is also possible that a host key has just been changed.
> The fingerprint for the ECDSA key sent by the remote host is
> SHA256:gJUlDrKOTnUQ/lAx6eM4Ylq6z/5ere2tJoLEgrfM++A.
> Please contact your system administrator.
> Add correct host key in /home/daniel/.ssh/known_hosts to get rid of this message.
> Offending ECDSA key in /home/daniel/.ssh/known_hosts:26
> remove with:
> ssh-keygen -f "/home/daniel/.ssh/known_hosts" -R hermes.apache.org
> ECDSA host key for hermes.apache.org has changed and you have requested strict checking.
> Host key verification failed.
> zsh: exit 255 ssh hermes.apache.org
> ]]]
>
> The error message does not give a way to continue the operation, but it
> does tell you what command to run if you would like to proceed anyway.
> This way, the buck stops with the user, but the program makes it quite
> clear that this is an abnormal situation and caution should be
> exercised.
>
> Should we do something similar (but without the all-caps? That's why
> I proposed writing a command that takes a certificate on stdin and marks
> it as trusted.
OpenSSH is an interesting example. The "known_hosts" file has been an
active detriment to DHCP based environments, where the same machine
may be rebuilt with the same hostname but a different IP address or
different hostkeys, for decades. The easy solution is to discard the
use of known_hosts, as documented all over the web, but summed up best
by these entries in /etc/ssh/ssh_config or in $HOME/.ssh/config
Host *
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
LogLevel ERROR
This trick is most useful in environments where people use svn+ssh and
the IP address of the Subversion server may change at unpredictable
times. It's also very useful for Jenkins, and Ansible, tasks that may
reach out to a Subversion server and don't want to have the
known_hosts fuss on a regular basis. known_hosts, like SSL certificat
signatures, has its security uses. But it has often proven a burden
rather than a blessing.
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
Posted by Pierre Fourès <pi...@gmail.com>.
Le sam. 20 juil. 2019 à 20:54, Daniel Shahaf <d....@daniel.shahaf.name> a écrit :
>
> Stefan Sperling wrote on Sat, 20 Jul 2019 09:51 +00:00:
> > But as a user I find it infuriating when software I use contains
> > artificial restrictions like this. We should assume our users know
> > what they are doing. Subversion is not a web browser.
>
> I'm not entirely sure I'm convinced by this logic. Let's take OpenSSH for example:
>
> [[[
> % ed .ssh/known_hosts
> g/^hermes/d
> s/^[^ ]*/hermes.apache.org/
> w
> q
> % ssh hermes.apache.org
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
> Someone could be eavesdropping on you right now (man-in-the-middle attack)!
> It is also possible that a host key has just been changed.
> The fingerprint for the ECDSA key sent by the remote host is
> SHA256:gJUlDrKOTnUQ/lAx6eM4Ylq6z/5ere2tJoLEgrfM++A.
> Please contact your system administrator.
> Add correct host key in /home/daniel/.ssh/known_hosts to get rid of this message.
> Offending ECDSA key in /home/daniel/.ssh/known_hosts:26
> remove with:
> ssh-keygen -f "/home/daniel/.ssh/known_hosts" -R hermes.apache.org
> ECDSA host key for hermes.apache.org has changed and you have requested strict checking.
> Host key verification failed.
> zsh: exit 255 ssh hermes.apache.org
> ]]]
>
> The error message does not give a way to continue the operation, but it
> does tell you what command to run if you would like to proceed anyway.
> This way, the buck stops with the user, but the program makes it quite
> clear that this is an abnormal situation and caution should be
> exercised.
>
> Should we do something similar (but without the all-caps? That's why
> I proposed writing a command that takes a certificate on stdin and marks
> it as trusted.
>
> Daniel
From a user perspective, I would also appreciate to be able to take my
responsibilities to accept unsafe operations. Having the choice to can
accept permanently the certificate, and then getting a special warning
message to confirm I really know what I do, because there is unknown
errors reported, would definitively help to report the responsibilities on
the users while let him/her chose to take (or not) the said responsibilities.
Best Regards,
Pierre.
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Sat, 20 Jul 2019 09:51 +00:00:
> But as a user I find it infuriating when software I use contains
> artificial restrictions like this. We should assume our users know
> what they are doing. Subversion is not a web browser.
I'm not entirely sure I'm convinced by this logic. Let's take OpenSSH for example:
[[[
% ed .ssh/known_hosts
g/^hermes/d
s/^[^ ]*/hermes.apache.org/
w
q
% ssh hermes.apache.org
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:gJUlDrKOTnUQ/lAx6eM4Ylq6z/5ere2tJoLEgrfM++A.
Please contact your system administrator.
Add correct host key in /home/daniel/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/daniel/.ssh/known_hosts:26
remove with:
ssh-keygen -f "/home/daniel/.ssh/known_hosts" -R hermes.apache.org
ECDSA host key for hermes.apache.org has changed and you have requested strict checking.
Host key verification failed.
zsh: exit 255 ssh hermes.apache.org
]]]
The error message does not give a way to continue the operation, but it
does tell you what command to run if you would like to proceed anyway.
This way, the buck stops with the user, but the program makes it quite
clear that this is an abnormal situation and caution should be
exercised.
Should we do something similar (but without the all-caps? That's why
I proposed writing a command that takes a certificate on stdin and marks
it as trusted.
Daniel
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Jul 19, 2019 at 09:52:32PM +0000, Daniel Shahaf wrote:
> Stefan Sperling wrote on Fri, 19 Jul 2019 18:45 +00:00:
> > It looks like the interactive prompt omits an option to save the cert
> > if it sees a certificate failure of class 'other' from the above list.
> > I am not sure why this decision was made but that's what the current
> > code seems to do.
>
> The rationale is that if we don't know what the failure reason _is_, we
> don't know whether it's safe to ignore it permanently. In other words,
> it only offers "permanently" if the failure bits are all whitelisted.
>
> The downside is that there's no easy way for a user to say "I know what
> I'm doing, and I _do_ want to ignore this permanently; make it so", such
> as a utility that takes a PEM form certificate (on, say, stdin) and
> marks it as permanently trusted.
At the point where we're already asking the user, we might as well
let the user decide what to do, in any case.
Yes, some people might then save a bad cert without knowing any better.
But as a user I find it infuriating when software I use contains
artificial restrictions like this. We should assume our users know
what they are doing. Subversion is not a web browser.
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Fri, 19 Jul 2019 18:45 +00:00:
> It looks like the interactive prompt omits an option to save the cert
> if it sees a certificate failure of class 'other' from the above list.
> I am not sure why this decision was made but that's what the current
> code seems to do.
The rationale is that if we don't know what the failure reason _is_, we
don't know whether it's safe to ignore it permanently. In other words,
it only offers "permanently" if the failure bits are all whitelisted.
The downside is that there's no easy way for a user to say "I know what
I'm doing, and I _do_ want to ignore this permanently; make it so", such
as a utility that takes a PEM form certificate (on, say, stdin) and
marks it as permanently trusted.
> So I suspect your SSL cert is failing for some reason
> other than unknown-ca, cn-mismatch, expired, not-yet-valid.
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Jul 19, 2019 at 08:38:57PM +0200, Stefan Sperling wrote:
> On Fri, Jul 19, 2019 at 01:40:52PM +0200, Pierre Fourès wrote:
> > Hi all,
> >
> > I have a script accessing an old svn server whom SSL certificate have
> > expired a long time ago. Up to now, I was permanently accepting the
> > certificate on the first run of the script and then everything was
> > sailling smooth. I reinstalled a couple of months ago a new box where
> > this script was intented to run and the (p)ermanently option seems not
> > provided anymore.
>
> If you're scripting 'svn' you should be using the --non-interactive option.
>
> In which case your script can use the --trust-server-cert-failures
> option to accept a cert in pre-determined failure cases.
>
> 'svn help update', for example, displays the following information
> section about the --trust-server-cert-failures option:
>
> --trust-server-cert-failures ARG : with --non-interactive, accept SSL server
> certificates with failures; ARG is comma-separated
> list of 'unknown-ca' (Unknown Authority),
> 'cn-mismatch' (Hostname mismatch), 'expired'
> (Expired certificate), 'not-yet-valid' (Not yet
> valid certificate) and 'other' (all other not
> separately classified certificate errors).
>
> Once your script uses this option it should work out of the box against
> your problematic server and there should be no need to save the cert.
Follow-up regarding your actual question:
It looks like the interactive prompt omits an option to save the cert
if it sees a certificate failure of class 'other' from the above list.
I am not sure why this decision was made but that's what the current
code seems to do. So I suspect your SSL cert is failing for some reason
other than unknown-ca, cn-mismatch, expired, not-yet-valid.
Additionally, the ability to save a cert is also disabled if the
--no-auth-cache option is used.
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Jul 19, 2019 at 01:40:52PM +0200, Pierre Fourès wrote:
> Hi all,
>
> I have a script accessing an old svn server whom SSL certificate have
> expired a long time ago. Up to now, I was permanently accepting the
> certificate on the first run of the script and then everything was
> sailling smooth. I reinstalled a couple of months ago a new box where
> this script was intented to run and the (p)ermanently option seems not
> provided anymore.
If you're scripting 'svn' you should be using the --non-interactive option.
In which case your script can use the --trust-server-cert-failures
option to accept a cert in pre-determined failure cases.
'svn help update', for example, displays the following information
section about the --trust-server-cert-failures option:
--trust-server-cert-failures ARG : with --non-interactive, accept SSL server
certificates with failures; ARG is comma-separated
list of 'unknown-ca' (Unknown Authority),
'cn-mismatch' (Hostname mismatch), 'expired'
(Expired certificate), 'not-yet-valid' (Not yet
valid certificate) and 'other' (all other not
separately classified certificate errors).
Once your script uses this option it should work out of the box against
your problematic server and there should be no need to save the cert.
Regards,
Stefan