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 <sfuentes AT umd DOT 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 <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/
> >
>
--
*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/
|
