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/