Bug#599161: xen-linux-system-2.6.32-5-xen-amd64: Clock moved forward 50 minutes, caused Xen HVM domU restart
In addition, I received the below from "James Song" but when I queried what it changed he did not respond, so I haven't tried it.. "added timer_mode =2 and tsc_mode = 1 and viridian=1 into your configure file." On Tue, Jan 04, 2011 at 04:56:00PM +, Mark Adams wrote: > Hi, > > No, unfortunately not. I just suffered it again aswell over the > Christmas break. Let me know if you find any fix. > > Regards, > Mark > > On Sun, Dec 26, 2010 at 12:50:26PM +0100, Moritz Muehlenhoff wrote: > > On Wed, Oct 06, 2010 at 12:05:18PM +0100, Mark Adams wrote: > > > > > > > As this is when the clock went from 18:00 to 18:50 and started the > > > > > chain > > > > > of events (restarted the 2008 domU). Any ideas why this log occurred? > > > > > > > > The TSC appeared to go backwards by a fairly significant amount, which > > > > has upset the kernel. > > > > > > > > The behaviour of the virtual TSC as seen by an HVM guest is controlled > > > > by a combination of the tsc_mode setting in your domain configuration > > > > and, I think, by the features of your specific hardware (some have > > > > constant rate TSC, others advertise varying levels of synchronisation > > > > between cores etc). It's then up to the guest kernel whether it even > > > > uses TSC as a timesource at all and how it handles instability etc and > > > > how it derives other time sources (such as the wallclock time) from it. > > > > > > > > Sorry this isn't more helpful, but as I say you will probably get better > > > > answers on one of the Xen mailing lists. > > > > > > Hi Ian, > > > > > > Thanks for your notes. I've already tried the xen-users list so I will > > > try xen-devel to see if I can glean any more information about my issue. > > > I will update the report here when I get any more information. > > > > Did you contact them? From what I read from the bug report so far, running > > an NTP client in the HVM host should suffice. > > > > Cheers, > > Moritz > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#599161: xen-linux-system-2.6.32-5-xen-amd64: Clock moved forward 50 minutes, caused Xen HVM domU restart
Hi, No, unfortunately not. I just suffered it again aswell over the Christmas break. Let me know if you find any fix. Regards, Mark On Sun, Dec 26, 2010 at 12:50:26PM +0100, Moritz Muehlenhoff wrote: > On Wed, Oct 06, 2010 at 12:05:18PM +0100, Mark Adams wrote: > > > > > As this is when the clock went from 18:00 to 18:50 and started the chain > > > > of events (restarted the 2008 domU). Any ideas why this log occurred? > > > > > > The TSC appeared to go backwards by a fairly significant amount, which > > > has upset the kernel. > > > > > > The behaviour of the virtual TSC as seen by an HVM guest is controlled > > > by a combination of the tsc_mode setting in your domain configuration > > > and, I think, by the features of your specific hardware (some have > > > constant rate TSC, others advertise varying levels of synchronisation > > > between cores etc). It's then up to the guest kernel whether it even > > > uses TSC as a timesource at all and how it handles instability etc and > > > how it derives other time sources (such as the wallclock time) from it. > > > > > > Sorry this isn't more helpful, but as I say you will probably get better > > > answers on one of the Xen mailing lists. > > > > Hi Ian, > > > > Thanks for your notes. I've already tried the xen-users list so I will > > try xen-devel to see if I can glean any more information about my issue. > > I will update the report here when I get any more information. > > Did you contact them? From what I read from the bug report so far, running > an NTP client in the HVM host should suffice. > > Cheers, > Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#600182: Acknowledgement (ntp: NTP switching from kernel time sync status change 4001 to 0001 caused server to stop responding)
Please close this bug report. The issue was found to be with a script that had overrun the server. I have noted that the bug regarding time sync changed is fixed in newer versions of ntp. Aplogies for the time wasting. Regards, Mark On Thu, Oct 14, 2010 at 11:45:08AM +, Debian Bug Tracking System wrote: > Thank you for filing a new Bug report with Debian. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Debian NTP Team > > If you wish to submit further information on this problem, please > send it to 600...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 600182: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=600182 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#599161: xen-linux-system-2.6.32-5-xen-amd64: Clock moved forward 50 minutes, caused Xen HVM domU restart
On Wed, Oct 06, 2010 at 11:47:05AM +0100, Ian Campbell wrote: > On Wed, 2010-10-06 at 09:33 +0100, Mark Adams wrote: > > Hi Ben, Thanks for your response. See my responses inline. > > > > On Wed, Oct 06, 2010 at 03:35:23AM +0100, Ben Hutchings wrote: > > > On Tue, 2010-10-05 at 09:31 +0100, Mark Adams wrote: > > > > Package: xen-linux-system-2.6.32-5-xen-amd64 > > > > Version: 2.6.32-21 > > > > Severity: important > > > > > > > > > > > > Hi, Did you receive this bug report? I hadn't received a bug ID even > > > > though receiving the copy of the original report. > > > > > > We don't have any other bug report with this description. > > > > > > > Likely because the address it was sent from originally was invalid. > > > > > > That would explain it. > > > > > > > - > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > > > > > > > Im running Xen 4.0.1-rc6 Debian squeeze with pvops 2.6.32-21 kernel. > > > > > > > > > > > > Today I noticed (when kerberos to the domain controllers stopped > > > > > > > > > > > > working..) that the clock was 50 minutes out in dom0 -- This caused the > > > > > > > > > > > > HVM windows domain controllers to have the wrong time. > > > > > > > > > > > > > > Since you appear to be in the UK, is it possible that the real-time > > > clock is set to local time (GMT+1) while Xen expects it to be GMT, or > > > vice versa? > > > > The clock is set with tzdata as BST yes, it is also set to this in the > > Windows server 2008 domU. We are using localtime=1 to match the clock > > in dom0 to domU. > > > > > > > > (This doesn't explain why it's 50 minutes out rather than 1 hour. But > > > ntpd will refuse to correct a large difference and the local clock may > > > then drift further.) > > > > > > [...] > > > > Can anyone confirm whether xen controls the time or the kernel? Also > > > > > > > > > > > > when I corrected the time in dom0 it was still wrong in HVM domU -- How > > > > > > > > > > > > long does it take for this to propogate? (I rebooted the VM's to > > > > correct > > > > > > > > it immediately). > > > > > > > > > > > [...] > > > > > > For HVM guests, the hypervisor emulates a standard PC real-time clock > > > and the guest uses that to initialise the system time, but there is no > > > way to force an update after the guest has booted unless the guest has > > > specific support for Xen; I assume Citrix does provide such software for > > > Windows but I don't know whether it is free software. > > > > The citrix WHQL drivers might have this functionality, I don't use them > > though - prefer the GPL PV drivers! (which don't have any clock support > > as far as I can tell) > > I think you can run a regular NTP client (assuming one exists for > Windows) in an HVM guest to keep wallclock time in sync. > > > > For PV guests, I assume you can force an update to the guest time using > > > the Xen management tools. > > > > > > Note, I'm just a general kernel maintainer and don't have any great > > > knowledge of Xen. > > I should know but time handling (particularly for HVM guests) is > something where
Bug#599161: xen-linux-system-2.6.32-5-xen-amd64: Clock moved forward 50 minutes, caused Xen HVM domU restart
Hi Ben, Thanks for your response. See my responses inline. On Wed, Oct 06, 2010 at 03:35:23AM +0100, Ben Hutchings wrote: > On Tue, 2010-10-05 at 09:31 +0100, Mark Adams wrote: > > Package: xen-linux-system-2.6.32-5-xen-amd64 > > Version: 2.6.32-21 > > Severity: important > > > > > > Hi, Did you receive this bug report? I hadn't received a bug ID even > > though receiving the copy of the original report. > > We don't have any other bug report with this description. > > > Likely because the address it was sent from originally was invalid. > > That would explain it. > > > - > > > > Hi All, > > > > > > > > Im running Xen 4.0.1-rc6 Debian squeeze with pvops 2.6.32-21 kernel. > > > > Today I noticed (when kerberos to the domain controllers stopped > > > > working..) that the clock was 50 minutes out in dom0 -- This caused the > > > > HVM windows domain controllers to have the wrong time. > > > > Since you appear to be in the UK, is it possible that the real-time > clock is set to local time (GMT+1) while Xen expects it to be GMT, or > vice versa? The clock is set with tzdata as BST yes, it is also set to this in the Windows server 2008 domU. We are using localtime=1 to match the clock in dom0 to domU. > > (This doesn't explain why it's 50 minutes out rather than 1 hour. But > ntpd will refuse to correct a large difference and the local clock may > then drift further.) > > [...] > > Can anyone confirm whether xen controls the time or the kernel? Also > > > > when I corrected the time in dom0 it was still wrong in HVM domU -- How > > > > long does it take for this to propogate? (I rebooted the VM's to correct > > > > it immediately). > > > [...] > > For HVM guests, the hypervisor emulates a standard PC real-time clock > and the guest uses that to initialise the system time, but there is no > way to force an update after the guest has booted unless the guest has > specific support for Xen; I assume Citrix does provide such software for > Windows but I don't know whether it is free software. The citrix WHQL drivers might have this functionality, I don't use them though - prefer the GPL PV drivers! (which don't have any clock support as far as I can tell) > > For PV guests, I assume you can force an update to the guest time using > the Xen management tools. > > Note, I'm just a general kernel maintainer and don't have any great > knowledge of Xen. All good, I have a feeling it might be a kernel issue rather than xen, but I'm still not sure what actually -controls- the time, is it the kernel? I think the key is in the log Oct 2 18:50:33 havhost1 kernel: [623480.977748] Clocksource tsc unstable (delta = -2999660303788 ns) > As this is when the clock went from 18:00 to 18:50 and started the chain of events (restarted the 2008 domU). Any ideas why this log occurred? > Ben. Regards, Mark > > -- > Ben Hutchings > Once a job is fouled up, anything done to improve it makes it worse. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#599161: xen-linux-system-2.6.32-5-xen-amd64: Clock moved forward 50 minutes, caused Xen HVM domU restart
Package: xen-linux-system-2.6.32-5-xen-amd64 Version: 2.6.32-21 Severity: important Hi, Did you receive this bug report? I hadn't received a bug ID even though receiving the copy of the original report. Likely because the address it was sent from originally was invalid. - Hi All, Im running Xen 4.0.1-rc6 Debian squeeze with pvops 2.6.32-21 kernel. Today I noticed (when kerberos to the domain controllers stopped working..) that the clock was 50 minutes out in dom0 -- This caused the HVM windows domain controllers to have the wrong time. I'm not sure if this is a kernel issue or a xen issue, but the only thing related is I can see the following in the kernel log: Oct 2 18:50:33 havhost1 kernel: [623480.977748] Clocksource tsc unstable (delta = -2999660303788 ns) But I also see in the dmesg log that xen is using it's own clock. [7.676563] Switching to clocksource xen I can't identify anything else in the logs to indicate when the time might have changed. I have a few other dom0 at the same level that haven't decided to change the time. Can anyone confirm whether xen controls the time or the kernel? Also when I corrected the time in dom0 it was still wrong in HVM domU -- How long does it take for this to propogate? (I rebooted the VM's to correct it immediately). It appears the HVM domU (windows server 2008) unexpectedly shut down at 18:51, after the unstable clocksource error. qemu-dm logs show a reset "reset requested in cpu_handle_ioreq." and xend.log shows a reboot Any other pointers on how to ensure stability of clocks from dom0 to domU HVM hosts (and pv for that matter..) would be appreciated. NTP was running but also appeared to have crashed at the same time. Cheers, Mark
Bug#592463: xen-linux-system-2.6.26-2-xen-amd64: domU kernel freeze on xfs location
Hi, Sorry, It's 2.6.26-19lenny2. Regards, Mark On Wed, Aug 11, 2010 at 04:25:28PM +0100, Ian Campbell wrote: > On Wed, 2010-08-11 at 16:21 +0100, Mark Adams wrote: > > Hi Ian, > > > > Thanks for your response. The kernel is linux-image-2.6.26-2-xen-amd64, > > installed via the xen-linux-system-2.6.26-2-xen-amd4 package. The issue > > occurred inside of a PV domU. > > But what are the versions of those packages? The numbers in the name are > the ABI version not the package version. > > Thanks, > Ian. > > -- > Ian Campbell > > Economics is extremely useful as a form of employment for economists. > -- John Kenneth Galbraith > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#592463: xen-linux-system-2.6.26-2-xen-amd64: domU kernel freeze on xfs location
Hi Ian, Thanks for your response. The kernel is linux-image-2.6.26-2-xen-amd64, installed via the xen-linux-system-2.6.26-2-xen-amd4 package. The issue occurred inside of a PV domU. Best Regards, Mark On Wed, Aug 11, 2010 at 04:13:11PM +0100, Ian Campbell wrote: > Thanks for your report. > > Looking at the stack trace I don't see much which is Xen-specific. The > only XFS vs. Xen interaction which I am aware of is the one addressed by > http://xenbits.xen.org/linux-2.6.18-xen.hg?rev/9bf1ddd0f6bf but I don't > think that is implicated here. > > Could this perhaps be a XFS rather than Xen bug? For example google > finds http://www.mail-archive.com/sa...@lists.samba.org/msg101509.html > which looks (superficially) similar. While googling I also got the > (perhaps mistaken) impression that lockdep warnings from XFS were not > uncommon in the past. > > I'm not really that familiar with XFS so I don't know to suggest next, > anyone else on debian-kernel have any ideas? I had a look over the > fs/xfs history in git and nothing leaps out at me. > > BTW, which exact kernel version do you have installed? > > Ian. > > On Tue, 2010-08-10 at 10:25 +0100, sysad...@campbell-lange.net wrote: > > Package: xen-linux-system-2.6.26-2-xen-amd64 > > Severity: important > > > > > > Hello, > > > > Yesterday we had a domU PV host freeze up in a file location. The > > following log was received: > > > > [20108008.237603] BUG: soft lockup - CPU#0 stuck for 61s! [smbd:16411] > > [20108008.237603] Modules linked in: appletalk ppdev parport_pc lp > > parport ipv6 xfs evdev ext3 jbd mbcache thermal_sys > > [20108008.237603] CPU 0: > > [20108008.237603] Modules linked in: appletalk ppdev parport_pc lp > > parport ipv6 xfs evdev ext3 jbd mbcache thermal_sys > > [20108008.237603] Pid: 16411, comm: smbd Not tainted 2.6.26-2-xen-amd64 > > #1 > > [20108008.237603] RIP: e030:[] [] > > :xfs:xfs_iext_get_ext 0xa/0x5a > > [20108008.237603] RSP: e02b:8800534dfa30 EFLAGS: 0202 > > [20108008.237603] RAX: 008d RBX: 8800534dfbe8 RCX: > > 008d > > [20108008.237603] RDX: 8800534dfc30 RSI: 008c RDI: > > 88006436bb60 > > [20108008.237603] RBP: 88008d43c8d0 R08: 008d R09: > > 0100 > > [20108008.237603] R10: 8800fdba73c0 R11: R12: > > 8800534dfbc8 > > [20108008.237603] R13: 88006436bb60 R14: 8800534dfc30 R15: > > 8800534dfc2c > > [20108008.237603] FS: 7f4198b83700() GS:8053a000() > > knlGS: > > [20108008.237603] CS: e033 DS: ES: > > [20108008.237603] DR0: DR1: DR2: > > > > [20108008.237603] DR3: DR6: 0ff0 DR7: > > 0400 > > [20108008.237603] > > [20108008.237603] Call Trace: > > [20108008.237603] [] ? > > :xfs:xfs_bmap_search_multi_extents 0x78/0xda > > [20108008.237603] [] ? :xfs:xfs_bmap_search_extents > > 0x5b/0xe6 > > [20108008.237603] [] ? :xfs:xfs_bmapi 0x26e/0xf76 > > [20108008.237603] [] ? error_exit 0x0/0x69 > > [20108008.237603] [] ? error_exit 0x0/0x69 > > [20108008.237603] [] ? :xfs:xfs_zero_eof 0xc0/0x16a > > [20108008.237603] [] ? :xfs:xfs_write 0x344/0x722 > > [20108008.237603] [] ? do_sync_write 0xc9/0x10c > > [20108008.237603] [] ? get_nsec_offset 0x9/0x2c > > [20108008.237603] [] ? __posix_lock_file 0x3c1/0x3f6 > > [20108008.237603] [] ? autoremove_wake_function > > 0x0/0x2e > > [20108008.237603] [] ? vfs_write 0xad/0x156 > > [20108008.237603] [] ? sys_pwrite64 0x50/0x70 > > [20108008.237603] [] ? sys_fcntl 0x2eb/0x2f7 > > [20108008.237603] [] ? system_call 0x68/0x6d > > [20108008.237603] [] ? system_call 0x0/0x6d > > [20108008.237603] > > > > This domU could not be rebooted, and had to be xm destroy then > > recreated again before the filesystem was accessible again. This > > machine has been running successfully for over 6 months before this > > issue occurred, and we run a number of other 2.6.26-2-xen machines > > that have not had this issue (fingers crossed!). If there is any > > explanation of this, how to avoid, or if it has been fixed in a newer > > kernel, this would be ideal. > > > > Thanks > > > > > > -- System Information: > > Debian Release: 5.0.5 > > APT prefers stable > > APT policy: (500, 'stable') > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/4 CPU cores) > > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) > > Shell: /bin/sh linked to /bin/bash > > > > > > > > -- > Ian Campbell > > Bennett's Laws of Horticulture: > (1) Houses are for people to live in. > (2) Gardens are for plants to live in. > (3) There is no such thing as a houseplant. > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.
Bug#426013: exim4-daemon-heavy Base64 decoding error
On Mon, Mar 03, 2008 at 06:41:05PM +0100, Marc Haber wrote: > On Mon, Mar 03, 2008 at 01:44:35PM +0000, Mark Adams wrote: > > All, This is now working as desired. I am using exactly the same > > configuration as I detailed in my first post (it was commented, I > > uncommented it.) > > > > MAIN_TLS_ENABLE = yes > > MAIN_TLS_PRIVATEKEY = /etc/exim4/certificates/newserver_co_uk.pem > > MAIN_TLS_CERTIFICATE = /etc/exim4/certificates/newserver_co_uk.crt > > > > Does anyone know if any recent updates could have corrected this > > problem? > > > > Regardless, I am very happy this is now working. Thanks to everyone that > > has looked in to this for me and provided help. > > If you send me the output of dpkg --list exim4-daemon-heavy, I can set > this bug to fixed with this version. 4.68-2 Thanks for your help and Patience Marc. > > Greetings > Marc Best Regards, Mark > > -- > - > Marc Haber | "I don't trust Computers. They | Mailadresse im Header > Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 > Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426013: exim4-daemon-heavy Base64 decoding error
> > Excellent, thank you. Could you also cut'n'paste your current exim > (MAIN_TLS_*) configuration? > > Which exim version are you using? Still 4.63-17? It would help if you > could post a short snippet of an updated error message, with the new > filenames and so on. > > When do the problem actually happen? Does it happen on all TLS > sessions, or just some? > > /Simon All, This is now working as desired. I am using exactly the same configuration as I detailed in my first post (it was commented, I uncommented it.) MAIN_TLS_ENABLE = yes MAIN_TLS_PRIVATEKEY = /etc/exim4/certificates/newserver_co_uk.pem MAIN_TLS_CERTIFICATE = /etc/exim4/certificates/newserver_co_uk.crt Does anyone know if any recent updates could have corrected this problem? Regardless, I am very happy this is now working. Thanks to everyone that has looked in to this for me and provided help. Best regards, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426013: exim4-daemon-heavy Base64 decoding error
Hi Simon, Thanks for the reply. Apologies for the confusion, I renamed .pem to .key in the middle of the process for my own clarification. the Certificate file does look like that, except it is much longer, atleast twice as long. it starts with the BEGIN line and ends with the END line. The .key file also begins with the BEGIN RSA PRIVATE KEY and ends with the right line. when I run certtool -k < newserver_co_uk.key the beginning starts with Public Key Info: Public Key Algorithm: RSA when I run certool -i < newerver_co_uk.crt It begins with the following output X.509 Certificate Information: Version: 3 Serial Number (hex): 78712b9b85f057731ea88fb1b9527153 Issuer: C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware Validity: Not Before: Thu May 10 00:00:00 UTC 2007 Not After: Sat May 9 23:59:59 UTC 2009 Subject Public Key Algorithm: RSA *NOTE* I have removed the Subject: line from this mail. Best regards, Mark On Thu, Feb 28, 2008 at 02:58:36PM +0100, Simon Josefsson wrote: > Hi! Looking over the entire bug report, I'm confused by the path names. > Early in your bug report the files were: > > MAIN_TLS_PRIVATEKEY = /etc/exim4/certificates/newserver_co_uk.pem > MAIN_TLS_CERTIFICATE = /etc/exim4/certificates/newserver_co_uk.crt > > This means the /etc/exim4/certificates/newserver_co_uk.crt file should > contain something like: > > -BEGIN CERTIFICATE- > MIICHjCCAYmgAwIBAgIERiYdNzALBgkqhkiG9w0BAQUwGTEXMBUGA1UEAxMOR251 > VExTIHRlc3QgQ0EwHhcNMDcwNDE4MTMyOTI3WhcNMDgwNDE3MTMyOTI3WjAdMRsw > GQYDVQQDExJHbnVUTFMgdGVzdCBjbGllbnQwgZwwCwYJKoZIhvcNAQEBA4GMADCB > iAKBgLtmQ/Xyxde2jMzF3/WIO7HJS2oOoa0gUEAIgKFPXKPQ+GzP5jz37AR2ExeL > ZIkiW8DdU3w77XwEu4C5KL6Om8aOoKUSy/VXHqLnu7czSZ/ju0quak1o/8kR4jKN > zj2AC41179gAgY8oBAOgIo1hBAf6tjd9IQdJ0glhaZiQo1ipAgMBAAGjdjB0MAwG > A1UdEwEB/wQCMAAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwDwYDVR0PAQH/BAUDAweg > ADAdBgNVHQ4EFgQUTLkKm/odNON+3svSBxX+odrLaJEwHwYDVR0jBBgwFoAU6Twc > +62SbuYGpFYsouHAUyfI8pUwCwYJKoZIhvcNAQEFA4GBALujmBJVZnvaTXr9cFRJ > jpfc/3X7sLUsMvumcDE01ls/cG5mIatmiyEU9qI3jbgUf82z23ON/acwJf875D3/ > U7jyOsBJ44SEQITbin2yUeJMIm1tievvdNXBDfW95AM507ShzP12sfiJkJfjjdhy > dc8Siq5JojruiMizAf0pA7in > -END CERTIFICATE- > > and the /etc/exim4/certificates/newserver_co_uk.pem file should contain > something like: > > -BEGIN RSA PRIVATE KEY- > MIICXAIBAAKBgQC7ZkP18sXXtozMxd/1iDuxyUtqDqGtIFBACIChT1yj0Phsz+Y8 > 9+wEdhMXi2SJIlvA3VN8O+18BLuAuSi+jpvGjqClEsv1Vx6i57u3M0mf47tKrmpN > aP/JEeIyjc49gAuNde/YAIGPKAQDoCKNYQQH+rY3fSEHSdIJYWmYkKNYqQIDAQAB > AoGADpmARG5CQxS+AesNkGmpauepiCz1JBF/JwnyiX6vEzUh0Ypd39SZztwrDxvF > PJjQaKVljml1zkJpIDVsqvHdyVdse8M+Qn6hw4x2p5rogdvhhIL1mdWo7jWeVJTF > RKB7zLdMPs3ySdtcIQaF9nUAQ2KJEvldkO3m/bRJFEp54k0CQQDYy+RlTmwRD6hy > 7UtMjR0H3CSZJeQ8svMCxHLmOluG9H1UKk55ZBYfRTsXniqUkJBZ5wuV1L+pR9EK > ca89a+1VAkEA3UmBelwEv2u9cAU1QjKjmwju1JgXbrjEohK+3B5y0ESEXPAwNQT9 > TrDM1m9AyxYTWLxX93dI5QwNFJtmbtjeBQJARSCWXhsoaDRG8QZrCSjBxfzTCqZD > ZXtl807ymCipgJm60LiAt0JLr4LiucAsMZz6+j+quQbSakbFCACB8SLV1QJBAKZQ > YKf+EPNtnmta/rRKKvySsi3GQZZN+Dt3q0r094XgeTsAqrqujVNfPhTMeP4qEVBX > /iVX2cmMTSh3w3z8MaECQEp0XJWDVKOwcTW6Ajp9SowtmiZ3YDYo1LF9igb4iaLv > sWZGfbnU3ryjvkb6YuFjgtzbZDZHWQCo8/cOtOBmPdk= > -END RSA PRIVATE KEY- > > Can you confirm that the files, respectively, have the proper headers? > > If the files contain anything else but content like the above, that may > be the problem. > > I don't understand what the .key file is. Can you confirm that > 'certtool -k /etc/exim4/certificates/newserver_co_uk.pem' works? > > It is important to run the tests on the exact same files as the ones > used by exim. > > Do you still get the exact same exim error message? Note that if the > *.crt and *.pem filenames are mixed up, that would explain everything. > > 2007-05-13 22:02:17 TLS error on connection from myhost.net [217.147.xx.xx] > (cert/key set up: cert=/etc/exim4/certificates/newserver_co_uk.crt > key=/etc/exim4/certificates/newserver_co_uk.pem) : Base64 decoding error. > > /Simon > > Mark Adams <[EMAIL PROTECTED]> writes: > > > Hi Simon, > > > > Apologies for the very late reply. > > > > certool works fine on the .crt file, but not on the .key - I get the > > Base64 decoding error. > > > > certtool: Import error: Base64 decoding error. > > > > The file appears to be in the correct format. > > > > Regards, > > Mark > > > > > > On Fri, Jan 04, 2008 at 12:22:51PM +0100, Simon Josefsson wrote: > >> Hi Mark! I'm trying to help debug this problem. Could you please post > >> the output from running
Bug#426013: Problems with specific certificate/key (Debian Bug #426013)
On Thu, Feb 28, 2008 at 12:51:46PM +, Mark Adams wrote: > On Wed, Feb 27, 2008 at 11:07:02PM +0200, Nikos Mavrogiannopoulos wrote: > > Mark Adams wrote: > >> On Jan 3, 2008 2:36 AM, Marc Haber <[EMAIL PROTECTED]> wrote: > > > >> I'm using gnutls 2.0.4 at present (this is the current debian testing > >> version). Is it possibly a known issue with this version? I can not > >> install the new version at present, as this is a production server. I > >> will be able to test this if you think it will correct the issue. > >> > >> For reference, gnutls-serv and gnutl-client work with this cert/key > >> pair. I can run the server fine using; > >> > >> gnutls-serv --debug 5 --x509keyfile myhost_net.key --x509certfile > >> myhost_net.crt > >> > >> And the client can connect using; > >> > >> gnutls-cli -p 5556 mail.myhost.net > >> > >> however, when using certtool -i < my key file failes with the base 64 > >> decoding error. > > > > This is normal. The -i parameter only reads certificates. You should use > > the -k option to parse the key. Do you use the same file to hold the key > > and the certificate? Also in your tests please use the -d 2 parameter to > > output more verbose information. > > > > regards, > > Nikos > > Hi, I have run this and all appears fine, please advise what output you > require. > > Please also advise what other tests I can run > > Regards > Mark I can confirm that it is the right format from this test; Public Key Info: Public Key Algorithm: RSA Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426013: exim4-daemon-heavy Base64 decoding error
On Fri, Jan 04, 2008 at 12:22:51PM +0100, Simon Josefsson wrote:
> Hi Mark! I'm trying to help debug this problem. Could you please post
> the output from running:
>
> certtool -i < /etc/exim4/certificates/newserver_co_uk.crt
>
> Could you also check that
>
> certtool -k < /etc/exim4/certificates/newserver_co_uk.pem
>
> works? Don't post the output, as that would compromise your private
> key.
>
> Do the files contain anything except one certificate and one private key
> respectively?
>
> The next step would be to install libgnutls-dbg and set a breakpoint on
> gnutls_certificate_set_x509_key_file to see where it fails.
>
> I'm trying to confirm that the problem only happens inside exim, and not
> inside gnutls. That seems strange, but the discussions in the bug
> report earlier suggests this.
>
> Fwiw, I believe this problem has nothing to do with a wildcard cert, the
> code that fails reads:
>
> DEBUG(D_tls) debug_printf("certificate file = %s\nkey file = %s\n",
> cert_expanded, key_expanded);
> rc = gnutls_certificate_set_x509_key_file(x509_cred, CS cert_expanded,
> CS key_expanded, GNUTLS_X509_FMT_PEM);
> if (rc < 0)
> {
> uschar *msg = string_sprintf("cert/key setup: cert=%s key=%s",
> cert_expanded, key_expanded);
> return tls_error(msg, host, rc);
> }
>
> That function does not care whether the certificate is a wildcard one.
>
> /Simon
Hi Simon,
I have tried the tests and they work, can you please advise how to go
about setting a breakpoint as you suggest for the next test?
Thanks,
Mark
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426013: Problems with specific certificate/key (Debian Bug #426013)
On Wed, Feb 27, 2008 at 11:07:02PM +0200, Nikos Mavrogiannopoulos wrote: > Mark Adams wrote: >> On Jan 3, 2008 2:36 AM, Marc Haber <[EMAIL PROTECTED]> wrote: > >> I'm using gnutls 2.0.4 at present (this is the current debian testing >> version). Is it possibly a known issue with this version? I can not >> install the new version at present, as this is a production server. I >> will be able to test this if you think it will correct the issue. >> >> For reference, gnutls-serv and gnutl-client work with this cert/key >> pair. I can run the server fine using; >> >> gnutls-serv --debug 5 --x509keyfile myhost_net.key --x509certfile >> myhost_net.crt >> >> And the client can connect using; >> >> gnutls-cli -p 5556 mail.myhost.net >> >> however, when using certtool -i < my key file failes with the base 64 >> decoding error. > > This is normal. The -i parameter only reads certificates. You should use > the -k option to parse the key. Do you use the same file to hold the key > and the certificate? Also in your tests please use the -d 2 parameter to > output more verbose information. > > regards, > Nikos Hi, I have run this and all appears fine, please advise what output you require. Please also advise what other tests I can run Regards Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426013: Problems with specific certificate/key (Debian Bug #426013)
On Jan 3, 2008 2:36 AM, Marc Haber <[EMAIL PROTECTED]> wrote: > Hi, > > Simon writes: > > Appears to be an unreprodicible problem with a specific > > certificate/key which the user cannot reveal. Another > > certificate/key > > from the same CA works fine. Theory: could it be CRLF problems? > > Other > > non-ASCII characters in the file? Nothing indicates a real GnuTLS > > problem here. > > Conclusion: Likely not a GnuTLS problem. > > I think that this conclusion was built too fast, but we do not have > sufficient information to know this. > > The original reporter has said in the mean time that there are no > non-ascii chars in the file and that there are no CRLF issues here. > Currently, it is suspected that GnuTLS has issues with the fact that > the certificate is a wildcard certificate. >By reading this report, I'm really curious which gnutls version is used, >and > >whether the gnutls-serv and exim are linked on the same version of >gnutls. >Does this occur if exim is linked on gnutls 2.2? > I'm using gnutls 2.0.4 at present (this is the current debian testing version). Is it possibly a known issue with this version? I can not install the new version at present, as this is a production server. I will be able to test this if you think it will correct the issue. For reference, gnutls-serv and gnutl-client work with this cert/key pair. I can run the server fine using; gnutls-serv --debug 5 --x509keyfile myhost_net.key --x509certfile myhost_net.crt And the client can connect using; gnutls-cli -p 5556 mail.myhost.net however, when using certtool -i < my key file failes with the base 64 decoding error. certtool: Import error: Base64 decoding error. > >regards, >Nikos Thanks for your interest, Regards Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426013: exim4-daemon-heavy Base64 decoding error
Hi Simon,
Apologies for the very late reply.
certool works fine on the .crt file, but not on the .key - I get the
Base64 decoding error.
certtool: Import error: Base64 decoding error.
The file appears to be in the correct format.
Regards,
Mark
On Fri, Jan 04, 2008 at 12:22:51PM +0100, Simon Josefsson wrote:
> Hi Mark! I'm trying to help debug this problem. Could you please post
> the output from running:
>
> certtool -i < /etc/exim4/certificates/newserver_co_uk.crt
>
> Could you also check that
>
> certtool -k < /etc/exim4/certificates/newserver_co_uk.pem
>
> works? Don't post the output, as that would compromise your private
> key.
>
> Do the files contain anything except one certificate and one private key
> respectively?
>
> The next step would be to install libgnutls-dbg and set a breakpoint on
> gnutls_certificate_set_x509_key_file to see where it fails.
>
> I'm trying to confirm that the problem only happens inside exim, and not
> inside gnutls. That seems strange, but the discussions in the bug
> report earlier suggests this.
>
> Fwiw, I believe this problem has nothing to do with a wildcard cert, the
> code that fails reads:
>
> DEBUG(D_tls) debug_printf("certificate file = %s\nkey file = %s\n",
> cert_expanded, key_expanded);
> rc = gnutls_certificate_set_x509_key_file(x509_cred, CS cert_expanded,
> CS key_expanded, GNUTLS_X509_FMT_PEM);
> if (rc < 0)
> {
> uschar *msg = string_sprintf("cert/key setup: cert=%s key=%s",
> cert_expanded, key_expanded);
> return tls_error(msg, host, rc);
> }
>
> That function does not care whether the certificate is a wildcard one.
>
> /Simon
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426013: exim4-daemon-heavy Base64 decoding error
No, permissions are correct. This seems to be a problem with wildcard SSL certs. Mark. On 24 Dec 2007, at 20:20, Florian Weimer <[EMAIL PROTECTED]> wrote: * Mark Adams: I this might sound daft, but are you really running these tests with the cert/key pair exim seems to have trouble with? (/etc/exim4/certificates/newserver_co_uk.crt and /etc/exim4/certificates/newserver_co_uk.pem) Hi Andreas, I know you have to ask. Yes this is being run with the keys that exim will show the 'Base64 decoding' error. Could this be a permission issue? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426013: exim4-daemon-heavy Base64 decoding error
Hello, I have checked this, they are ASCII only with unix line endings. Could it be something to do with the * ? (wildcard certificate) Mark On Tue, Dec 11, 2007 at 12:41:13PM +0100, Marc Haber wrote: > On Tue, Dec 11, 2007 at 11:16:43AM +0000, Mark Adams wrote: > > I have tried this again with the reissued certificate. Unfortunately the > > same error still occurs. > > Can you please verify whether your certificate and key use 0A (LF > only) line breaks and do not contain non-ASCII characters? > > Greetings > Marc > > -- > - > Marc Haber | "I don't trust Computers. They | Mailadresse im Header > Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 > Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426013: exim4-daemon-heavy Base64 decoding error
Hello, I have tried this again with the reissued certificate. Unfortunately the same error still occurs. It appears this must be something to do with the fact that this is a wildcard certificate (*.domain.co.uk) as the exact configuration works fine on other servers with single host certificates. (mail.domain.co.uk) Mark On Tue, Dec 04, 2007 at 11:46:44AM +0100, Marc Haber wrote: > On Wed, Sep 05, 2007 at 08:27:36PM +0200, Marc Haber wrote: > > Currently, the bug is unreproducible for me. > > Just for the record, the certificate/key that I used on my system were > ASCII text files with "0A" (LF only) line breaks, and contained no > non-ASCII chars by virtue of > | sudo cat /etc/exim4/tls/certs/comodo.crt /etc/exim4/tls/key/comodo.key | > LANG=C grep '[^-+/=a-zA-Z0-9 ]' > > Greetings > Marc > > -- > - > Marc Haber | "I don't trust Computers. They | Mailadresse im Header > Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 > Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426013: exim4-daemon-heavy Base64 decoding error
Hi Marc, You can obtain a free 90 day trial certificate from this company, see http://www.instantssl.com/ssl-certificate-products/free-ssl-certificate.html This is the company that I purchased my cert from, they are comodo resellers I would be very greatful if you would be interested in looking in to this further. Best Regards, Mark > > I am afraid that I do not know what is going on here, and that locally > debugging would require me to purchase a certificate from your vendor > just to find out which options and encodings they use and why GnuTLS > does not grok them. I cannot afford doing this. > > Tagging the bug accordingly. > > Greetings > Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426013: exim4-daemon-heavy Base64 decoding error
On Sat, Jun 30, 2007 at 08:43:19AM +0200, Marc Haber wrote: > I still do not see the exact command lines that were used to obtain > this output on both sides. For server; gnutls-serv --debug 5 --x509keyfile myhost_net.key --x509certfile myhost_net.crt And for Client; gnutls-cli -p 5556 mail.myhost.net > > But it looks right, I forgot that gnutls-serv implements an echo > service. > > I am afraid that I do not know what is going on here, and that locally > debugging would require me to purchase a certificate from your vendor > just to find out which options and encodings they use and why GnuTLS > does not grok them. I cannot afford doing this. > I am going to query the company to see if they can provide me with any help. Is there anything you would like to know that I can ask them? > Tagging the bug accordingly. > > Greetings > Marc Thanks, Mark > > -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426013: exim4-daemon-heavy Base64 decoding error
On Thu, Jun 28, 2007 at 01:15:33PM +0200, Marc Haber wrote: > On Wed, Jun 20, 2007 at 04:47:27PM +0100, Mark Adams wrote: > > When using gnutls-cli to connect to the client whilst running the > > gnutls-server command I get the following response > > > > - Peer's certificate issuer is unknown > > - Peer's certificate is NOT trusted > > - Version: TLS 1.0 > > - Key Exchange: DHE RSA > > - Cipher: AES 256 CBC > > - MAC: SHA > > - Compression: DEFLATE > > - Handshake was completed > > > > - Simple Client Mode: > > > > When you type things in the client, do they show up in the server and > vice versa? Which command lines do you use? When I type "hello" in the client (for instance) I get "hello" back in the client. (see log below for server side reponses) When I type "hello" in the server, I get nothing back there, and nothing in the client. using gnutls-cli -p 5556 hostname Apologies for long log here but I did not want to miss anything out. Echo Server ready. Listening to port '5556'. |<4>| REC[547060]: Expected Packet[0] Handshake(22) with length: 1 |<4>| REC[547060]: Received Packet[0] Handshake(22) with length: 140 |<4>| REC[547060]: Decrypted Packet[0] Handshake(22) with length: 140 |<3>| HSK[547060]: CLIENT HELLO was received [140 bytes] |<3>| HSK[547060]: Client's version: 3.2 |<2>| ASSERT: gnutls_db.c:327 |<2>| ASSERT: gnutls_db.c:247 |<3>| HSK[547060]: Selected Compression Method: DEFLATE |<2>| EXT[547060]: Received extension 'CERT_TYPE' |<2>| EXT[547060]: Received extension 'SERVER_NAME' |<2>| ASSERT: gnutls_handshake.c:2674 |<3>| HSK[547060]: Removing ciphersuite: ANON_DH_ARCFOUR_MD5 |<2>| ASSERT: gnutls_handshake.c:2674 |<3>| HSK[547060]: Removing ciphersuite: ANON_DH_3DES_EDE_CBC_SHA1 |<2>| ASSERT: gnutls_handshake.c:2674 |<3>| HSK[547060]: Removing ciphersuite: ANON_DH_AES_128_CBC_SHA1 |<3>| HSK[547060]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1 |<3>| HSK[547060]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1 |<3>| HSK[547060]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1 |<3>| HSK[547060]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1 |<3>| HSK[547060]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1 |<3>| HSK[547060]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1 |<3>| HSK[547060]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1 |<3>| HSK[547060]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1 |<3>| HSK[547060]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[547060]: Keeping ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[547060]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1 |<3>| HSK[547060]: Keeping ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1 |<3>| HSK[547060]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1 |<3>| HSK[547060]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[547060]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1 |<2>| ASSERT: gnutls_handshake.c:2674 |<3>| HSK[547060]: Removing ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 |<2>| ASSERT: gnutls_handshake.c:2674 |<3>| HSK[547060]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA1 |<2>| ASSERT: gnutls_handshake.c:2664 |<3>| HSK[547060]: Removing ciphersuite: RSA_EXPORT_ARCFOUR_40_MD5 |<3>| HSK[547060]: Keeping ciphersuite: RSA_ARCFOUR_SHA1 |<3>| HSK[547060]: Keeping ciphersuite: RSA_ARCFOUR_MD5 |<3>| HSK[547060]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[547060]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 |<3>| HSK[547060]: Selected cipher suite: RSA_AES_128_CBC_SHA1 |<3>| HSK[547060]: SessionID: ca761ceecc5a61803da38f461c324b39ac67e0e3c91ccc242cc7cfbcd621fd68 |<3>| HSK[547060]: SERVER HELLO was send [74 bytes] |<4>| REC[547060]: Sending Packet[0] Handshake(22) with length: 74 |<4>| REC[547060]: Sent Packet[1] Handshake(22) with length: 79 |<4>| REC[547060]: Sent Packet[1] Handshake(22) with length: 79 |<3>| HSK[547060]: CERTIFICATE was send [1359 bytes] |<4>| REC[547060]: Sending Packet[1] Handshake(22) with length: 1359 |<4>| REC[547060]: Sent Packet[2] Handshake(22) with length: 1364 |<3>| HSK[547060]: CERTIFICATE REQUEST was send [9 bytes] |<4>| REC[547060]: Sending Packet[2] Handshake(22) with length: 9 |<4>| REC[547060]: Sent Packet[3] Handshake(22) with length: 14 |<3>| HSK[547060]: SERVER HELLO DONE was send [4 bytes] |<4>| REC[547060]: Sending Packet[3] Handshake(22) with length: 4 |<4>| REC[547060]: Sent Packet[4] Handshake(22) with length: 9 |<2>| ASSERT: gnutls_buffers.c:289 |<2>| ASSERT: gnutls_buffers.c:1087 |<2>| ASSERT: gnutls_handshake.c:949
Bug#426013: exim4-daemon-heavy Base64 decoding error
This note was unclear. I meant, "when using gnutls-cli to connect to the server whilst it is running the gnutls-server command I get the following reponse" .. How can I test this with openssl? is there any other tests I can do to help this issue ? Regards, Mark On Wed, Jun 20, 2007 at 04:47:27PM +0100, Mark Adams wrote: > Hi There, > > When using gnutls-cli to connect to the client whilst running the > gnutls-server command I get the following response > > - Peer's certificate issuer is unknown > - Peer's certificate is NOT trusted > - Version: TLS 1.0 > - Key Exchange: DHE RSA > - Cipher: AES 256 CBC > - MAC: SHA > - Compression: DEFLATE > - Handshake was completed > > - Simple Client Mode: > > > Is it failing because of the first 2 responses? this doesn't seem to > relate to any "base64 decoding" error? > > Thanks, > Mark > > On Thu, Jun 07, 2007 at 09:39:52PM +0200, Marc Haber wrote: > > On Wed, May 30, 2007 at 08:37:04PM +0100, Mark Adams wrote: > > > Hi Andreas, I know you have to ask. Yes this is being run with the keys > > > that exim will show the 'Base64 decoding' error. > > > > What happens when you use gnutls-serv and/or openssl s_server with > > this certificate and connect to the server with the appropriate (or > > the other) client? > > > > Greetings > > Marc > > > > -- > > - > > Marc Haber | "I don't trust Computers. They | Mailadresse im Header > > Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 > > Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426013: exim4-daemon-heavy Base64 decoding error
Hi There, When using gnutls-cli to connect to the client whilst running the gnutls-server command I get the following response - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS 1.0 - Key Exchange: DHE RSA - Cipher: AES 256 CBC - MAC: SHA - Compression: DEFLATE - Handshake was completed - Simple Client Mode: Is it failing because of the first 2 responses? this doesn't seem to relate to any "base64 decoding" error? Thanks, Mark On Thu, Jun 07, 2007 at 09:39:52PM +0200, Marc Haber wrote: > On Wed, May 30, 2007 at 08:37:04PM +0100, Mark Adams wrote: > > Hi Andreas, I know you have to ask. Yes this is being run with the keys > > that exim will show the 'Base64 decoding' error. > > What happens when you use gnutls-serv and/or openssl s_server with > this certificate and connect to the server with the appropriate (or > the other) client? > > Greetings > Marc > > -- > - > Marc Haber | "I don't trust Computers. They | Mailadresse im Header > Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 > Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- Mark Adams Technical Manager Campbell-Lange Workshop Ltd 3 Tottenham Street W1T 2AF telephone 02076311555 mobile 07809718932 [EMAIL PROTECTED] www.campbell-lange.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426013: exim4-daemon-heavy Base64 decoding error
... On Sun, May 27, 2007 at 10:43:45AM +0200, Andreas Metzler wrote: > On 2007-05-26 Mark Adams <[EMAIL PROTECTED]> wrote: > [...] > >> Does > >> openssl s_server -debug -key exim.key -cert exim.crt > >> work? > >> And how about > >> gnutls-serv --debug 5 --x509keyfile exim.key --x509certfile exim.crt > > > Both of these appear to work fine; > > > openssl response; > > Using default temp DH parameters > > Using default temp ECDH parameters > > ACCEPT > > > > gnutls response; > > Echo Server ready. Listening to port '5556'. > > I this might sound daft, but are you really running these tests with > the cert/key pair exim seems to have trouble with? > (/etc/exim4/certificates/newserver_co_uk.crt and > /etc/exim4/certificates/newserver_co_uk.pem) Hi Andreas, I know you have to ask. Yes this is being run with the keys that exim will show the 'Base64 decoding' error. > > cu andreas Regards, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426013: exim4-daemon-heavy Base64 decoding error
Package: exim4-daemon-heavy Version: 4.63-17 Hi, Currently trying to setup SMTPS with a comodo ssl certificate. This is an RSA cert encoded as Base64. The following error is received; 2007-05-13 22:02:17 TLS error on connection from myhost.net [217.147.xx.xx] (cert/key set up: cert=/etc/exim4/certificates/newserver_co_uk.crt key=/etc/exim4/certificates/newserver_co_uk.pem) : Base64 decoding error. config used; MAIN_TLS_ENABLE = yes MAIN_TLS_PRIVATEKEY = /etc/exim4/certificates/newserver_co_uk.pem MAIN_TLS_CERTIFICATE = /etc/exim4/certificates/newserver_co_uk.crt Please advise if more information is required. -- Mark Adams -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
