That is probably due to: SSLACCEPTCERTFROMSERV - The default value Yes enables the client to automatically accept a self-signed public certificate from the server, and to automatically configure the client to use that certificate when the client connects to a V8.1.2 or later server.
On Tue, Oct 10, 2017 at 11:58 AM, Sergio O. Fuentes <sfuen...@umd.edu> wrote: > My digicert signed certs are loaded into the server cert.kdb using the > gsk8apicmd functions. That's working. My question was getting those > non-existent root and intermediate CA certs loaded into the client. > Normally, in order to get SSL working, you need the whole signing chain on > the client (not the private TSM server signed cert). In prior versions to > 8.1.2 you had to manually add any commercial root certs that were not > included in the original dsmcert.kdb. > > I just did a quick test on a new client, and it looks like the whole public > cert chain is negotiated correctly with a CA signed certificate. > > Initial environment was with the admin client (dsmadmc) and admin > sessionsecurity=transitional. Both server and client are on the same > machine 8.1.3 server and 8.1.2 client. I'm not sure if that factored into > the negotiation. > > So far, I think we're in good shape to have this pushed out in the next two > weeks to production. We'll be upgrading the servers first and the ops > center shortly thereafter. Then we'll be recommending that all clients > start the upgrade process (providing SSL guidance where necessary). > Therefore, most of our admins and nodes will be in the transitional state > for quite some time. > > Thanks! > Sergio > > > On Tue, Oct 10, 2017 at 10:43 AM, Zoltan Forray <zfor...@vcu.edu> wrote: > > > As I read it, "vendor-acquired certificates" need to be loaded/added to > the > > server using the gsk8capicmd function. This link, while it's for 7.1.1, > > talks about it: > > > > https://www.ibm.com/support/knowledgecenter/en/SSGSG7_7.1. > > 1/com.ibm.itsm.tshoot.doc/r_pdg_ssl_comm.html > > > > On Tue, Oct 10, 2017 at 10:00 AM, Sergio O. Fuentes <sfuen...@umd.edu> > > wrote: > > > > > I have one other question for any IBMers or people who may have had > > > experience with this: > > > > > > If 8.1.2 clients can negotiate certificates with a 8.1.3 TSM server, > does > > > this mean that for users who use third-party signed certificates (not > > > loaded by default in the TSM client) that the certificate chain will > > > automatically be loaded to an 8.1.2 client? For example, we use > digicert > > > signed certs. Digicert is not one of the pre-loaded root certificates > in > > > the TSM client (Verisign and Thawte are). Can an 8.1.2 client > negotiate > > > the entire cert chain or will we be required to load the root and > > > intermediate digicert certs into the client? > > > > > > To ask more directly, how can I petition IBM to release a client with > > > pre-loaded DigiCert CA certificates? > > > > > > Thanks! > > > Sergio > > > > > > On Mon, Oct 9, 2017 at 12:14 PM, Skylar Thompson < > > skyl...@u.washington.edu > > > > > > > wrote: > > > > > > > Content preview: I definitely agree with this; at least for TSM v7 > it > > > > would > > > > have been far better to call it v7.2.0 to make it clear that > it's a > > > > huge > > > > change with lots of caveats and potential failure points. We've > just > > > > now discovered > > > > that TSM v7.1.8 does not play nicely with GPFS/mmbackup due to a > > > > change in > > > > how SSL certificates are loaded - hopefully it's a simple fix but > > who > > > > knows... > > > > [...] > > > > > > > > Content analysis details: (0.7 points, 5.0 required) > > > > > > > > pts rule name description > > > > ---- ---------------------- ------------------------------ > > > > -------------------- > > > > 0.7 SPF_NEUTRAL SPF: sender does not match SPF record > > > > (neutral) > > > > -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover > > > relay > > > > domain > > > > X-Barracuda-Connect: mx.gs.washington.edu[128.208.8.134] > > > > X-Barracuda-Start-Time: 1507565699 > > > > X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 > > > > X-Barracuda-URL: https://148.100.49.27:443/cgi-mod/mark.cgi > > > > X-Barracuda-Scan-Msg-Size: 1182 > > > > X-Virus-Scanned: by bsmtpd at marist.edu > > > > X-Barracuda-BRTS-Status: 1 > > > > X-Barracuda-Spam-Score: 0.00 > > > > X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of > > > > TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.5 tests= > > > > X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.43739 > > > > Rule breakdown below > > > > pts rule name description > > > > ---- ---------------------- ------------------------------ > > > > -------------------- > > > > > > > > I definitely agree with this; at least for TSM v7 it would have been > > far > > > > better to call it v7.2.0 to make it clear that it's a huge change > with > > > lots > > > > of caveats and potential failure points. We've just now discovered > that > > > TSM > > > > v7.1.8 does not play nicely with GPFS/mmbackup due to a change in how > > SSL > > > > certificates are loaded - hopefully it's a simple fix but who > knows... > > > > > > > > On Sat, Oct 07, 2017 at 02:36:13PM -0500, Roger Deschner wrote: > > > > > This difficulty comes up while there are open, now-published > security > > > > > vulnerabilities out there inviting exploits, and making our > Security > > > > > people very nervous. But the considerations described in > > > > > http://www-01.ibm.com/support/docview.wss?uid=swg22004844 make it > > very > > > > > difficult and risky to proceed with 7.1.8/8.1.3 as though it was > > just a > > > > > patch. It's a major upgrade, requiring major research and planning, > > > with > > > > > the threat of an exploit constantly hanging over our heads. I > really > > > > > wish this had been handled differently. > > > > > > > > -- > > > > -- Skylar Thompson (skyl...@u.washington.edu) > > > > -- Genome Sciences Department, System Administrator > > > > -- Foege Building S046, (206)-685-7354 > > > > -- University of Washington School of Medicine > > > > > > > > > > > > > > > -- > > *Zoltan Forray* > > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator > > Xymon Monitor Administrator > > VMware Administrator > > Virginia Commonwealth University > > UCC/Office of Technology Services > > www.ucc.vcu.edu > > zfor...@vcu.edu - 804-828-4807 > > Don't be a phishing victim - VCU and other reputable organizations will > > never use email to request that you reply with your password, social > > security number or confidential personal information. For more details > > visit http://phishing.vcu.edu/ > > > -- *Zoltan Forray* Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon Monitor Administrator VMware Administrator Virginia Commonwealth University UCC/Office of Technology Services www.ucc.vcu.edu zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://phishing.vcu.edu/
