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 <zforray AT vcu DOT 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 <sfuentes AT umd DOT 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 <
> skylar2 AT u.washington DOT 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 (skylar2 AT u.washington DOT 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
> zforray AT vcu DOT 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/
>
|
