Yep, running z/VM 5.2. Here is my secure telnet PORT statement: 8823 TCP VTUBESSL SECURE ALCERT ; SECURE TELNET TO VTUBESSL Here is my SSLADMIN QUERY STATUS : ssladmin query status
Maximum number of sessions: 100 Number of active sessions: 0 Administration port: 9999 Cipher_suites included : RC4_128_SHA RC4_128_MD5 TRIPLE_DES_SHA RC4_US RC2_US DES_1024_SHA RC4_56_SHA DES_40_SHA RC4_40_MD5 RC2_40_MD5 DES_56_SHA NULL_SHA NULL_MD5 NULL Cipher_suites exempted : Trace Settings: Normal: OFF Connections: OFF Flow: OFF Address: 255.255.255.255:0 Connection: 0 My SSLADMIN QUERY CERT ALCERT: ssladmin query cert ALCERT Certificate information: Label: ALCERT Version: 3 Serial number: 482c91bf Issued by: MAINFRAME.ALEXLEE.COM ALEXLEE INC. HICKORY, NC USA Belongs to: MAINFRAME.ALEXLEE.COM ALEXLEE INC. HICKORY, NC USA Effective dates: May 14 2008 to May 16 2011 Type: Server Key Size: 1024 I do notice my NETSTAT CONN (SELECT SSLSERV shows : netstat conn (select sslserv VM TCP/IP Netstat Level 520 Active IPv4 Transmission Blocks: User Id Conn Local Socket Foreign Socket State ---- -- ---- ----- ------ ------- ------ ----- SSLSERV 1226 *..1025 *..* Listen SSLSERV 1046 127.0.0.0..9999 *..* Listen Active IPv6 Transmission Blocks: None Should I not have a port 8823 socket, or would it only show for an active session? What is the 1025 for? Tim ________________________________ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Adam Thornton Sent: Wednesday, August 06, 2008 10:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SSL connection problem after IPL On Aug 6, 2008, at 9:35 AM, Tim Joyce wrote: Hey Adam, Thanks for the reply. Here is my DF command: df Filesystem 1K-blocks Used Available Use% Mounted on /dev/dasda1 139368 127316 12052 92% / tmpfs 63040 0 63040 0% /dev/shm /dev/dasdb1 656 32 592 6% /opt/vmssl/parms Is 92 % ok? How should I clean up the log files? 92% is fine. Judging from the partition size, you're running z/VM 5.2 or earlier, right? As far as PROFILE TCPIP errors, I did notice yesterday I had misspelled the PORT 9999 statement for my SSLSERV admin : 9999 TCP SSLSERV SERCUR ALCERT ; SSL SERVER - ADMINISTRATION so I corrected with obeyfile : 9999 TCP SSLSERV SECURE ALCERT ; SSL SERVER - ADMINISTRATION If this is the problem, I do not understand why it would have worked before the IPL. And, if this was the issue, shouldn't the corrected obeyfile have resolved this, or will I need to wait until I can cycle the TCPIP stack this weekend? If it worked before IPL it was probably that someone had done an OBEYFILE last time, but I would think an OBEYFILE would have worked this time. How about the ports that you're actually using to connect SSL services on? What do those look like? Do they have the right certificate names? Adam