|
<snip>1) Check if the SSL enabled *ADMIN server is even running. Do a NETSTAT *CNN from your as/400, and see if there's anything listening on port 2010. If not, it's not running. Check QSYSOPR for messages, and also check the spool for job logs that might be related.</snip> SSL is running on the *admin server, Here is the netstat.... But I don't see port 2010, no messages in QSYSOPR, or Job logs Remote Remote Local Address Port Port Idle Time State * * ftp-con > 001:36:21 Listen * * telnet 000:56:02 Listen * * smtp 000:18:55 Listen * * www-http 000:04:46 Listen * * 99 000:05:54 Listen * * pop3 000:00:11 Listen * * netbios > 741:40:55 Listen * * netbios > 000:03:23 *UDP * * netbios > 000:03:23 *UDP * * netbios > 002:01:52 Listen * * snmp 741:40:55 *UDP * * https 000:04:46 Listen <<<-------?????? * * as-svrmap 000:56:04 Listen * * lpd 741:41:17 Listen * * as-admi > 000:00:36 Listen * * as-admi > 000:00:36 Listen * * as-mgtc > 021:54:03 Listen * * 6555 741:40:55 *UDP * * as-cent > 000:56:04 Listen * * as-data > 021:49:36 Listen * * as-dtaq 741:41:20 Listen * * as-file 020:56:31 Listen * * as-netprt 741:41:20 Listen * * as-rmtcmd 000:58:46 Listen * * as-signon 000:56:04 Listen * * as-netd > 741:41:20 Listen * * as-tran > 741:41:20 Listen * * as-vrtp > 741:41:20 Listen * * 9090 047:03:56 Listen -----Original Message----- From: midrange-l-admin@midrange.com [mailto:midrange-l-admin@midrange.com] On Behalf Of Scott Klement Sent: Tuesday, July 16, 2002 11:19 AM To: midrange-l@midrange.com Subject: Re: Problem with SSL Hi, The reason that it "just sits there" when you try to connect to port 2001, is because that's the regular (non-SSL) port. It's connected, and trying to enable SSL, but since that port doesn't do SSL, nothing happens. As for why port 2010 doesn't work, I'd try narrowing down the problem a bit. 1) Check if the SSL enabled *ADMIN server is even running. Do a NETSTAT *CNN from your as/400, and see if there's anything listening on port 2010. If not, it's not running. Check QSYSOPR for messages, and also check the spool for job logs that might be related. 2) See if you can connect from the LAN. If you can connect from the LAN, then the server is working properly, and the problem is a firewall/routing/NAT issue. 3) If the LAN works, and you're using NAT, you might need to make sure that the domain name from teh outside is the same as the domain name from the inside. It's possible that the name you're connecting as doesn't match the name on the certificate, which might cause SSL to think somethings wrong. Hope that helps... On Tue, 16 Jul 2002, Justin Houchin wrote: > > Hi Everyone, > I am trying to get a secure connection to my *ADMIN Server > Instance. I have my test system certificate installed from VeriSign. I > have gone into the "Security configuration" and setup the SSL > connection, SSL Port 2010, SSl Client Authentication-Optional. I have > gone into the Digital Certificate Manager and did a "work with secure > applications". I assigned my VeriSign certificate to > QIBM_HTTP_SERVER_ADMIN. I shutdown and restarted the *admin server > instance. I downloaded the test CA certificate to my web browser from > VeriSign. I pass port 2001 and port 2010 through the firewall to the > 400. I connect to my home computer using PcAnywhere to simulate being on > a machine outside of the firewall. I pull up a web browser and type > https://www.reliatek.com:2001...the > <https://www.reliatek.com:2001...the/> machine sits there like it is > trying to load. I check the netstat on the 400 and it shows > 24.216.***.** 2035 as-admi > 000:00:06 Established, but > nothing happens. When I type in https://www.reliatek.com:2010 > <https://www.reliatek.com:2010/> , it says page cannot be displayed. Any > Suggestions???? > > _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l or email: MIDRANGE-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.