Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
  • 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)
share|improve this question

8 Answers 8

There's a couple of solutions to get around the problem that come to mind. First, you could create a new webdav virtual host in Apache that does not use this certificate (plain http). Alternatively, you could use the svn+ssh access method and private key authentication for the cron job (may be a security risk).

I'd only go this route if you can't fix the problems with the certificate, or aren't tied to https webdav access though.

share|improve this answer
    
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. –  Tom Ritter Jun 17 '09 at 3:51
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.

share|improve this answer
    
Sorry it's taken so long, but I tried this and it's still not working =/ –  Tom Ritter Jul 14 '09 at 12:05
    
what does your certificate now say? –  David Pashley Jul 14 '09 at 15:51
    
Ah, I see you've updated the question. Now your problem is that you're using a self-signed certificate. You can just accept this either for just this connection or for all time. If you press "p" it should just work. –  David Pashley Jul 14 '09 at 15:57
1  
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. –  David Pashley Jul 14 '09 at 16:00

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.

share|improve this answer

you can just:

echo t | svn update --username yourusername--password yourpassword --no-auth-cache /local.repository/path 2>/dev/null
share|improve this answer

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.

share|improve this answer

The answers to this question helped me assemble the pieces needed to solve a similar problem i was having. This is just to pre-assemble the pieces for other linux noobs like me.

to test the script you run via cron use

sudo su

instead of what I was using

sudo -s

otherwise the home directory and other variables won't be as when it is run by cron(root)

secondly don't use "--no-auth-cache". If you add that switch you can never permanently accept the certificate.

using the above, I was able to run the script once via sudo su, accept the certificate permanently and subsequent cron runs worked.

share|improve this answer

You might try validating the certificate manually:

$ openssl x509 -noout -fingerprint -in cert.pub
MD5 Fingerprint=0D:89:07:D6:4F:BC:84:2E:2E:14:C2:DA:D4:3B:D5:7C
share|improve this answer

Put this in your script:

# svn up /BACKUP/checkouts/server/ --username tom –config-dir /xyz/zyx

config-dir could be anything where you want to store the certificate information. Before running it from the cron, run it manually and accept the certificate permanently, using "p".

Once accepted, run it through cron and I believe it will work like a charm.

There is one more option (if previous option doesn't work by any chance), which is kind of risky in other environments, but in your environment, it should be fine. Use the script something like this:

# svn up /BACKUP/checkouts/server/ --username tom --non-interactive –-trust-server-cert

This will simply accept the certificate without bothering. This is not advised in the production environment because this is kind of a security risk, but in your case, where you are using self made certificate, you can use it.

Source: GeekRide

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.