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: [email protected]
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
