svn won't accept my invalid certificate

Question

• I have a server running apache with a self-signed certificate (the server) with subversion hooked in
• It requires a username to checkout or update from the repo.
• I have a checkout from the repo that I am trying to update on a cron job on two servers: server and client. Neither cron job will work for the same reason (I have almost the same setup on both, but the client is simpler).
• The following are on client, where there is only one login: root (I know, please spare me the ridicule)
• they are both gentoo if you think that matters

error

Error validating server certificate for 'https://server:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
 - The certificate hostname does not match.
Certificate information:
 - Hostname: Tom
 - Valid: from Sun, 01 Feb 2009 03:51:25 GMT until Tue, 01 Feb 2011 03:51:25 GMT
 - Issuer: Fake Company, NYC, New York, US
 - Fingerprint: fingerprint here

   (R)eject, accept (t)emporarily or accept (p)ermanently? 
svn: OPTIONS of 'https://server/svn/repo': Server certificate verification failed: certificate issued for a different hostname, issuer is not trusted (https://server)

I know all this. That's why I followed all the guides to get svn to automatically accept the certificate:

/root/.subversion/servers

[global]
ssl-authority-files = /root/scripts/server.crt

/root/scripts/server.crt

-----BEGIN CERTIFICATE-----
MIIDejCCAmICCQDibo0twimetjANBgkqhkiG9w0BAQUFADB/MQswCQYDVQQGEwJV
UzERMA8GA1UECBMITmV3IFlvcmsxDDAKBgNVBAcTA05ZQzEjMCEGA1UEChMaSGFw
et al
-----END CERTIFICATE-----

/root/scripts/backup.sh

svn up /BACKUP/checkouts/server/ --username tom

And the command runs fine as root (no sudo, directly as root) with no prompting for confirming a certificate (it had previously, but I chose p for accept permanently).

Does anyone know why my script won't work? It's been annoying me for the past several months.

**Edit:**It's taken me a bit to get back to this, and I followed David's advice, but it still doesn't work. Now the error is:

Error validating server certificate for 'https://server:443':
 - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: server
 - Valid: from Sat, 20 Jun 2009 14:10:45 GMT until Mon, 20 Jun 2011 14:10:45 GMT
 - Issuer: Fake Company, New York, US
 - Fingerprint: 1a:c6:9c:eb:62:9e:e1:05:d9:d3:ac:01:f4:35:dc:00:14:48:e5:39
(R)eject, accept (t)emporarily or accept (p)ermanently? svn: OPTIONS of 'https://server/svn/folder': Server certificate verification failed: issuer is not trusted (https://server)

Solution 1

Error validating server certificate for 'https://server:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
 - The certificate hostname does not match.
Certificate information:
 - Hostname: Tom
 - Valid: from Sun, 01 Feb 2009 03:51:25 GMT until Tue, 01 Feb 2011 03:51:25 GMT
 - Issuer: Fake Company, NYC, New York, US
 - Fingerprint: fingerprint here

The problem is that your certificate does not match your server's hostname. You need the CN field in the certificate to match your hostname. In yuor case, your hostname is "server" and your certificate's CN is "Tom". You need to regenerate your certificate with the correct CN value.

Solution 2

One thing to note - many cron jobs run w/ a different HOME (e.g. /etc/crontab (cron.daily etc) sets HOME=/) so it has a different .subversion file. Just bit us here and there was a /.subversion tree w/o the accepted cert. Setting HOME correctly in the cron script fixed it.

Solution 3

Did you try to set ssl-trust-default-ca to true? I dont know if will solve your problem but I saw this recomendation at Version Control with Subversion book.

Many OpenSSL installations also have a pre-defined set of “default” CAs that are nearly universally trusted. To make the Subversion client automatically trust these standard authorities, set the ssl-trust-default-ca variable to true.

Solution 4

just add this to the arguments

--trust-server-cert-failures="other,unknown-ca,cn-mistmatch,expired" 

View more solutions

Comments

[Tom Ritter]

I could (re)enable HTTP for only the internal network and still require HTTPS for external, hadn't thought of that. But I'm still hoping to get this working since there is a way I'm just doing something wrong.

[David Pashley]

what does your certificate now say?

[David Pashley]

If you want the cron job to work, you would probably have to do the checkout by hand once and accept the certificate. Then it should work.