Mike I can see I left out details that would have made things a bit easier to understand - Please accept my apologies. Having said that, the first draft of a response to the points you raise included a _lot_ of information, and I eventually threw that draft away. Please understand that I'm not trying to be secretive - I'm just trying to avoid a 'TL/DR' response. My use of localhost is Ok in the environment I'm in. I can use that or the DNS name, or the IPaddress - they are all practically interchangeable for my purposes. Note the word 'practically' there, though. If I use DNS or IPAddr to get to z/OSMF, I get a security warning in the browser window which I have to respond to before getting to the logon screen. If I use localhost, that warning does not appear, so really it's just a way of saving a (small) amount of time.
Your later comments about the z/OSMF server certificate coincided with my recognition of the significance of the KEYRING_NAME parm in IZUPRMxx. My only prior use of z/OSMF was to use the Configuration Assistant to create the config files necessary for implementing AT-TLS on the system. After a few false starts (it was my _very_ first use of z/OSMF) everything went fine, and there were no instances of z/OSMF wanting to use the REST API to get information from somewhere else, so no 'connection refused' problem occurred. I've never modified and used the supplied IZUSEC job because I haven't needed to. Everything was previously done by the team that created our z/OS system in the first place - or so I thought. With this current use of z/OSMF, the use of a server certificate has raised its head. Now it would appear that I've got to put some work in on that front; to make sure all the RACF permissions are in place and so on. But I'm a bit confused. On the one hand I can see the need for the correct definition and handling of the server certificate, but APAR PH10056 says (in part): The z/OSMF server port uses Java SSL encryption to protect its outbound HTTPS connections. Therefore, it is not necessary (or possible) to configure AT-TLS on the z/OSMF server port. If you attempt to do so, the z/OSMF server will encounter HTTP connection failures and errors, such as the following, in the server logs directory: 1. IZUG476E: The HTTP request to the secondary z/OSMF instance "209" failed with error type "CertificateError" and response code "0" 2. javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection? That second error message is exactly the one I'm seeing in the server log at the time the 'connection refused' error occurs. So right now I'm at a bit of a loss when it comes to reconciling the apparent contradiction here. As I say, I've never touched the IZUSEC job it appears but it _has_ been used and is now interfering with z/OSMF's activities. I _have_ introduced AT-TLS on the system, but that is restricted to controlling TN3270 and SFTP work - there's no mention of port 10443 or stuff associated with z/OSMF in the AT-TLS config files. I 've obviously got some more digging to do... Regards Sean On Tue, 9 Jun 2020 at 07:43, Sean Gleann <sean.gle...@gmail.com> wrote: > Thank you Dave - I was unaware of that qualification. > Checked and, yes, 'localhost' is defined in my RESOLVER parameters > > Sean > > > On Mon, 8 Jun 2020 at 17:33, Mike Wawiorko < > 0000014ab5cdfb21-dmarc-requ...@listserv.ua.edu> wrote: > >> I hope I'm understanding what you are saying. >> >> Localhost is for use ONLY within a single TCPIP stack or system. It is >> another way of writing non-routable IP address '127.0.0.1'. >> Maybe configuring host files will allow you to do this but that will be >> very confusing and awkward to support. >> >> You should NOT be using localhost to get from your device (PC or >> whatever) to the z/OS TCPIP stack. >> >> You should configure a name for your ZOSMF IP address. >> If you always run ZOSMF on the same z/OS system you may already have a >> suitable name in DNS for the system's static VIPA. >> If you move ZOSMF between systems in the sysplex you will need a Dynamic >> Virtual IP Address (DVIPA) and an entry in DNS (or host files) for it. >> >> I'm struggling to follow what you are saying about PuTTY for SSH and your >> Opera browser. >> >> You might use your SSH connection to get to z/OS and work with USS and >> perform some configuration actions. You do not use PuTTY to logon to ZOSMF. >> >> You should have a ZOSMF server certificate signed by a CA trusted by your >> browser. >> This certificate should - probably must - include the DNS name as a >> subject alternate name. >> >> When you make the HTTPS connection from the browser Opera will validate >> the security of the connection. That will include: >> 1. Check that it is indeed HTTPS and not HTTP >> 2. Check for TLS1.2 - lower levels of SSL / TLS are often not allowed >> these days >> 3. Check the ZOSMF server certificate Is signed by a CA trusted by Opera >> 4. Check certificate dates >> 5. Confirm the DNS you used to reach ZOSMF is named as a subject >> alternate name >> >> Browsers have an icon to click showing why a connection is not secure. It >> will very likely be one of the steps above. >> >> Some browsers allow you to allow connections with an untrusted >> certificate. That would be a bad security practice but may allow an initial >> connection. >> >> Hope some of this helps. It is generic advice for any browser connection >> to z/OS. >> >> Mike Wawiorko >> >> >> -----Original Message----- >> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf >> Of Sean Gleann >> Sent: 08 June 2020 14:15 >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: AZD messages? >> >> >> This message originated from outside our organisation and is from web >> based email - sean.gle...@gmail.com >> >> As far as I understand things, 'localhost' is just another way of saying >> '127.0.0.1' meaning 'this computer', so - yes, localhost is defined. >> I have an SSH connection defined in PuTTY that associates my local 10443 >> with the host system's 10443, and I start that connection before attempting >> to go to https://localhost:10443 in my browser (Opera). >> I'm quite happy to be shown any error in my understanding, however. >> >> But you've sparked off another train of thought, Lloyd. >> Whilst it's true I get to my z/OSMF with 'https://localhost:10443/zosmf', >> the very first thing I see is a warning that the connection is not secure >> and I have to click on 'continue anyway' in order to get to the z/OSMF >> sign-on screen. >> I think I've got to sort out *that* problem before trying to go any >> further. >> >> Regards >> Sean >> >> , >> >> >> This e-mail and any attachments are confidential and intended solely for >> the addressee and may also be privileged or exempt from disclosure under >> applicable law. If you are not the addressee, or have received this e-mail >> in error, please notify the sender immediately, delete it from your system >> and do not copy, disclose or otherwise act upon any part of this e-mail or >> its attachments. >> Internet communications are not guaranteed to be secure or virus-free. >> The Barclays Group does not accept responsibility for any loss arising from >> unauthorised access to, or interference with, any Internet communications >> by any third party, or from the transmission of any viruses. Replies to >> this e-mail may be monitored by the Barclays Group for operational or >> business reasons. >> Any opinion or other information in this e-mail or its attachments that >> does not relate to the business of the Barclays Group is personal to the >> sender and is not given or endorsed by the Barclays Group. >> Barclays Execution Services Limited provides support and administrative >> services across Barclays group. Barclays Execution Services Limited is an >> appointed representative of Barclays Bank UK plc, Barclays Bank plc and >> Clydesdale Financial Services Limited. Barclays Bank UK plc and Barclays >> Bank plc are authorised by the Prudential Regulation Authority and >> regulated by the Financial Conduct Authority and the Prudential Regulation >> Authority. Clydesdale Financial Services Limited is authorised and >> regulated by the Financial Conduct Authority. >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
