The normal generalised TLS flow is.... 1. Client sends stuff to the server initiating the handshake. 2. Server sends stuff to the client, and can include the server's certificate. 3. Client can be configured to check the server's certificate. Eg check the signer's CA is in the clients store. Check the IP address from the server, matches the IP address within the certificate(SAN) 4. Server can send down "Client must send certificate" 5. Client sends its certificate. (or picks the best one (if it has more than one) depending on what the server sent down) 6. Server must have the CA used to sign the client's certificate etc It does all of the checking
If the certificates which are being sent up and down are self signed, then the other end needs a copy of the same certificate, so it can compare them. If the certificates are signed by a CA, then having the same CA at each end should be ok. Colin On Wed, 14 Jun 2023 at 14:47, Rasmussen, A. (Andre) < 000004eb5e8da660-dmarc-requ...@listserv.ua.edu> wrote: > If it is a personal certificate both parties will share there respective > public and signer/authorisation/CA keys with each other for the transfer to > work. The only certificate you don't share of course is your private key. > Hope this helps. > > Andre > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf > Of Jake Anderson > Sent: Friday, June 09, 2023 08:16 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Personal certificate Connect direct secure plus > > ⚠️ CAUTION: EXTERNAL SENDER - Please be careful when opening links and > attachments. ⚠️ Please report any suspicious mail to > phish...@nedbank.co.za. Nedbank Information Security > > When a client connect direct secure plus intiiates the connection to a > server connect direct secure plus with OVERRIDE=Y > > In this case the client needs the server certificates copy right ? Cause > there is a confusion whether the client certificate needs to be uploaded to > the server(as per our security guy) > > Could someone please clarify? > > On Thu, Jun 8, 2023, 7:55 PM Lenich, Victoria A CTR DODHRA DMDC (USA) < > 00000a95d73aa270-dmarc-requ...@listserv.uga.edu> wrote: > > > I have done the certificates in Connect Direct Secure Plus. > > After you get the certificates from your CA, you have to update > > several panels in Connect Direct. > > I usually get help from IBM support to walk me through the panels. > > There is also, an order to do it with the remote site. > > IBM has some papers out on the internet about how to implement it. > > Vicki Lenich > > > > -----Original Message----- > > From: RACF Discussion List <rac...@listserv.uga.edu> On Behalf Of > > Charles Mills > > Sent: Thursday, June 8, 2023 8:34 AM > > To: rac...@listserv.uga.edu > > Subject: Re: Personal certificate Connect direct secure plus > > > > Yes, generally speaking, if you need a certificate the process is to > > create a CSR, get it signed, and then install and trust it and put it > > on a keyring. > > > > There is lots of Certificate basic education on the SHARE Web site and > > on NewEra zExchange. > > > > Charles > > > > > > -----Original Message----- > > From: RACF Discussion List [mailto:rac...@listserv.uga.edu] On Behalf > > Of Jake Anderson > > Sent: Thursday, June 8, 2023 7:02 AM > > To: rac...@listserv.uga.edu > > Subject: Personal certificate Connect direct secure plus > > > > Hello > > > > I must agree that am not an expert in certificate. > > > > Just wanted to understand if we must create a new CSR for personal > > Certauth and get it signed and trusted ? > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ******************** > Nedbank Limited group of companies (Nedbank) disclaimer and > confidentiality notice: > > This email, including any attachments (email), contains information that > is confidential and is meant only for intended recipients. You may not > share or copy the email or any part of it, unless the sender has > specifically allowed you to do so. If you are not an intended recipient, > please delete the email permanently and let Nedbank know that you have > deleted it by replying to the sender or calling the Nedbank Contact Centre > on +27 (0)800 555 111 (local) or +27 (0)10 2170 000 (international). > > This email is not confirmation of a transaction or a Nedbank statement and > is not offering or inviting anyone to take up any financial products or > services, unless the content specifically indicates that it does so. > Nedbank will not be liable for any errors or omissions in this email. The > views and opinions are those of the author and not necessarily those of > Nedbank. > > The names of the Nedbank Board of Directors and Company Secretary are > available here: www.nedbank.co.za/terms/DirectorsNedbank.htm. Nedbank Ltd > Reg No 1951/000009/06. > ******************** > > ---------------------------------------------------------------------- > 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
