[prev in list] [next in list] [prev in thread] [next in thread]
List: racf-l
Subject: Re: Certificates not connected to a Key Ring and Expiring CERTAUTH certificates
From: Wai Choi <wchoi () US ! IBM ! COM>
Date: 2020-05-01 16:40:19
Message-ID: OFE4135831.AD3FFF63-ON0025855B.004E165F-8525855B.005B94E4 () notes ! na ! collabserv ! com
[Download RAW message or body]
Pete,
So you are talking about a similar case. By digging into information
provided by the Sectigo, I found the another cross certificate issued by a
different root.
To avoid the confusion, I won't use the same set of letters A, B, B' and
C. I use P, Q, Q' and R for the set of certificates you use.
AAA is another root the company wants to replace. It still has 8 years of
life. But it already signed a cross certificate last year to prepare for
its expiration. Let's call this P
Start Date: 2003/12/31 20:00:00
End Date: 2028/12/31 19:59:59
Serial Number:
>01<
Issuer's Name:
>CN=AAA Certificate Services.O=Comodo CA Limited.L=Salford.SP=Greater
<
>Manchester.C=GB<
Subject's Name:
>CN=AAA Certificate Services.O=Comodo CA Limited.L=Salford.SP=Greater
<
>Manchester.C=GB<
Signing Algorithm: sha1RSA
The newer root is this. Let's call this Q
Start Date: 2010/01/31 20:00:00
End Date: 2038/01/18 19:59:59
Serial Number:
>01FD6D30FCA3CA51A81BBC640E35032D<
Issuer's Name:
>CN=USERTrust RSA Certification Authority.O=The USERTRUST
Network.L=Je<
>rsey City.SP=New Jersey.C=US<
Subject's Name:
>CN=USERTrust RSA Certification Authority.O=The USERTRUST
Network.L=Je<
>rsey City.SP=New Jersey.C=US<
Signing Algorithm: sha384RSA
The cross certificate is this, it was created last year. Let's call this
Q'
Start Date: 2019/03/11 20:00:00
End Date: 2028/12/31 19:59:59
Serial Number:
>3972443AF922B751D7D36C10DD313595<
Issuer's Name:
>CN=AAA Certificate Services.O=Comodo CA Limited.L=Salford.SP=Greater
<
>Manchester.C=GB<
Subject's Name:
>CN=USERTrust RSA Certification Authority.O=The USERTRUST
Network.L=Je<
>rsey City.SP=New Jersey.C=US<
Signing Algorithm: sha384RSA
If you have all of these CAs in RACF, depends on which certificate it
finds first, you will get a different result in LISTCHAIN:
XCICS<--R<--Q, if Q is added before Q'
XCICS<--R<--Q'<--P, if Q' is added before Q.
You can try by removing and adding Q and Q' in a different order.
But the bottom line is either chain works for certificate validation until
the cross certificate expires. My recommendation is to keep the minimal
number of certificates in the keyring. A simple keyring is always easier
to maintain.
Regards,
Wai
Wai Choi - RACF/PKI Design and Development
Tie-line:295-7623
External: (845)435-7623
Internet: wchoi@us.ibm.com
From: BUCKLEY Pete <pete.buckley@AXA.COM>
To: RACF-L@LISTSERV.UGA.EDU
Date: 05/01/2020 06:09 AM
Subject: Re: [EXTERNAL] Re: Certificates not connected to a Key
Ring and Expiring CERTAUTH certificates
Sent by: RACF Discussion List <RACF-L@LISTSERV.UGA.EDU>
Thank you Wai for the usual clear and detailed explanation.
As for the AAA root certificate, the validation chain goes from:
(Old) XCICS <--C<--B'<--A
To
(New) XCICS<--C<--AAA
RACDCERT LISTCHAIN shows this new validation chain only when B' is deleted
(or presumably, expired).
Out of curiosity:
If multiple possible validation chains exist, how does LISTCHAIN determine
which to display?
Are all possible validation chains actually valid?
To give a practical example, say that I have all the above certificates in
my database.
Would both the following keyrings for XCICS be valid:
XCICS+C+B'+A
XCICS+C+AAA
Regards,
Pete BUCKLEY
AXA
Internal
-----Original Message-----
From: RACF Discussion List <RACF-L@LISTSERV.UGA.EDU> On Behalf Of Wai Choi
Sent: 30 April 2020 23:18
To: RACF-L@LISTSERV.UGA.EDU
Subject: [EXTERNAL] Re: Certificates not connected to a Key Ring and
Expiring CERTAUTH certificates
For an end entity certificate bought from a commercial Certificate
Authority, it is never issued directly from a root certificate. There must
be some intermediate CA(s). The certificate authority will take care of
all the root, intermediate CA certificates before they expire and you will
not get an end entity certificate issued by an expiring issuer.
From the link provided, I gathered some information and hope the
explanation helps the understanding of the potential issue in the RACF
keyring.
The expiring Sectigo (rebranded from Comodo) AddTrust root certificate is
this, let's call it A:
Start Date: 2000/05/30 06:48:38
End Date: 2020/05/30 06:48:38
Serial Number:
>01<
Issuer's Name:
>CN=AddTrust External CA Root.OU=AddTrust External TTP
Network.O=AddTr<
>ust AB.C=SE<
Subject's Name:
>CN=AddTrust External CA Root.OU=AddTrust External TTP
Network.O=AddTr<
>ust AB.C=SE<
Signing Algorithm: sha1RSA
Cross certification is a common technique to introduce a new root CA by
making use of the already widely known root CA.
The newer root certificate is this, let's call it B:
Start Date: 2010/01/18 20:00:00
End Date: 2038/01/18 19:59:59
Serial Number:
>4CAAF9CADB636FE01FF74ED85B03869D<
Issuer's Name:
>CN=COMODO RSA Certification Authority.O=COMODO CA
Limited.L=Salford.S<
>P=Greater Manchester.C=GB<
Subject's Name:
>CN=COMODO RSA Certification Authority.O=COMODO CA
Limited.L=Salford.S<
>P=Greater Manchester.C=GB<
Signing Algorithm: sha384RSA
The cross certificate is this. It has the same subject name and public
key as the new root CA. It was signed by the old root. Let's call this B':
Start Date: 2000/05/30 06:48:38
End Date: 2020/05/30 06:48:38
Serial Number:
>2766EE56EB49F38EABD770A2FC84DE22<
Issuer's Name:
>CN=AddTrust External CA Root.OU=AddTrust External TTP
Network.O=AddTr<
>ust AB.C=SE<
Subject's Name:
>CN=COMODO RSA Certification Authority.O=COMODO CA
Limited.L=Salford.S<
>P=Greater Manchester.C=GB<
Signing Algorithm: sha384RSA
The intermediate CA that signed your end entity certificate since 2010
(most likely) should be signed by B. Let's call the intermediate CA C, and
the end entity certificate X
So depending on which root CA you have in your RACF keyring, the
validation chain ends up differently.
If your system has A (old system), the validation chain is X<--C<--B'<--A
If your system has B (new system), the validation chain is X<--C<--B
With cross certification, it gives time for the CA to introduce the newer
root and gives time for the customer to trust the newer root. Now the
expiration time of the old root certificate A and the cross certificate B'
is coming, the system relying on A will need to be fixed.
You will need B in the system and connect it to the keyring. A and B are
two different certificates, adding B does not affect the existence of A.
Once you add B, B will be used. You can delete A or you may leave it there
until it expires. You can delete B' too, if it is there.
I don't see how the AAA root certificate mentioned related to the expiring
AddTrust certificate at all. It is not expiring soon (2028). Does it have
cross certificate too? I am not sure what old CA certs it is replacing.
Regards,
Wai
Wai Choi - RACF/PKI Design and Development
From: BUCKLEY Pete <pete.buckley@AXA.COM>
To: RACF-L@LISTSERV.UGA.EDU
Date: 04/30/2020 04:05 AM
Subject: Re: [EXTERNAL] Re: Certificates not connected to a Key
Ring and Expiring CERTAUTH certificates
Sent by: RACF Discussion List <RACF-L@LISTSERV.UGA.EDU>
I think this might be what you're referring to:
https://urldefense.proofpoint.com/v2/url?u=https-3A__support.sectigo.com_articles_Know \
ledge_Sectigo-2DAddTrust-2DExternal-2DCA-2DRoot-2DExpiring-2DMay-2D30-2D2020-3FretURL- \
3D-252Fapex-252FCom-5FKnowledgeWeb2Casepagesectigo-26popup-3Dfalse&d=DwIGaQ&c=jf_iaSHv \
JObTbx-siA1ZOg&r=r7eqrQPTrezFZjW1SX1mXg&m=3HTVecQD-cn3HSlTWI78kRF--JHsQJTqQVB-mqo90JE&s=z3-C5cWuLL48Np9BNOc42lcS6FajrUWg407xX9N5bFg&e= \
I'm trying to do some testing on this at the moment. My initial finding
was that the new AAA certificate only replaced the old CA certs when they
were deleted (according to Listchain). Hopefully the same applies when
they expire, as suggested by the article and the linked FAQ.
Disclaimer: I'm definitely no expert in this area.
Pete BUCKLEY
AXA
Internal
-----Original Message-----
From: RACF Discussion List <RACF-L@LISTSERV.UGA.EDU> On Behalf Of Susan
Marvel
Sent: 29 April 2020 19:29
To: RACF-L@LISTSERV.UGA.EDU
Subject: [EXTERNAL] Re: Certificates not connected to a Key Ring and
Expiring CERTAUTH certificates
The part about the new certauth and need to re-sign--that is my experience
too. But, I have also experienced cases where the expiring cert seems
overlaid by the new one (and by that I mean that I no longer see the
expiring one in RACF). I had run across some documentation that I thought
explained circumstances under which this can happen, but I haven't been
able to re-locate it and I may have been misunderstanding it.
Sue
-----Original Message-----
From: RACF Discussion List <RACF-L@LISTSERV.UGA.EDU> On Behalf Of VANDER
WOUDE, PETER
Sent: Wednesday, April 29, 2020 1:19 PM
To: RACF-L@LISTSERV.UGA.EDU
Subject: Re: Certificates not connected to a Key Ring and Expiring
CERTAUTH certificates
Susan,
I had to look up the virtual key rings, as I've not used them. They
actually had to specify the keyring being <keyownerid>/* at the queue
manager level, along with the reference to the certificate, which is owned
by <keyownerid>. Without specifying the virtual keyring name, they can't
use ssl in the queue manager.
I re-read your other question regarding the expiring certauth records.
When I've had to deal with this, the new certauth record is exactly that,
new and does not replace any current.
If any certificate is signed by the certauth that is expiring, then, in my
experience, you would have to have your certificate signed by the new
certificate authority.
I could be wrong, so if others have better experience with this, please
chime in
Regards,
Peter
-----Original Message-----
From: RACF Discussion List <RACF-L@LISTSERV.UGA.EDU> On Behalf Of Susan
Marvel
Sent: Wednesday, April 29, 2020 2:06 PM
To: RACF-L@LISTSERV.UGA.EDU
Subject: Re: Certificates not connected to a Key Ring and Expiring
CERTAUTH certificates
Thanks, Peter.
I think in this case, no ring was specified, only the label of the cert.
Sue
-----Original Message-----
From: RACF Discussion List <RACF-L@LISTSERV.UGA.EDU> On Behalf Of VANDER
WOUDE, PETER
Sent: Wednesday, April 29, 2020 12:58 PM
To: RACF-L@LISTSERV.UGA.EDU
Subject: Re: Certificates not connected to a Key Ring and Expiring
CERTAUTH certificates
*** ATTENTION! This message originated from outside of Ensono. Treat
hyperlinks and attachments in this email with caution. ***
Susan,
In regards to your comment about your customer is using a specific
certificate label, instead of a keyring. That is the way that MQseries
works when using SSL authentication, afaik.
In the queue manager base config, you define the keyring and you have to
default certificate label to use for the queue manager. For each separate
channel, you can either use the default named in the queue manager, or the
channel can be configured to use another certificate that is in the
keyring defined for use by the queue manager.
Regards,
Peter
-----Original Message-----
From: RACF Discussion List <RACF-L@LISTSERV.UGA.EDU> On Behalf Of Susan
Marvel
Sent: Wednesday, April 29, 2020 1:28 PM
To: RACF-L@LISTSERV.UGA.EDU
Subject: Certificates not connected to a Key Ring and Expiring CERTAUTH
certificates
CAUTION: This email originated from outside the organization. Do not click
links or open attachments unless you recognize the sender and know the
content is safe.
First of all, I apologize if this has already been covered in a thread
before I joined this list, but I have several questions.
• There is an upcoming group of CA certs that are replacing CA certs
that expire at the end of May. It is my understanding that the
cross-signing should not have an adverse effect on the use of digital
certificates. (COMDO RSA Certification Authority and USERTrust RSA
Certification Authority.) When I go to add these, will they overlay the
existing certs that are expiring, simply extending the expiration date,
but not changing the public key? If the expiring certs have signed user
certs, do those user certs need to be re-signed?
• I have just found out (to my dismay) that one of our customers is
using virtual rings (for FTPS). I don't have experience in this area and
have always relied on a certificate being connected to a non-virtual ring
to determine whether it is being used. When I replace the above
certificates (and maybe the answer depends on whether the certs are being
"overlaid" as I mention above), how would I know which cert is actually
being used—the old or new one, particularly in the case where the old one
has not yet expired?
I hope my questions make sense. Replacing CERTAUTHs has always been a
concern to me and I know "virtually" nothing about virtual rings. 😊
On a separate topic, I recently found out that this same customer was
referring to the Label of a cert being used for MQSeries and not a ring.
Again, because the certs were not connected to any rings, both the
customer and I assumed they were not being used. Fortunately we
discovered this in time to replace the expiring certs.
Thank you so much!
Sue Marvel
________________________________
CONFIDENTIALITY NOTICE: This e-mail message and all attachments may
contain legally privileged and confidential information intended solely
for the use of the addressee. If the reader of this message is not the
intended recipient, any reading, dissemination, distribution, copying, or
other use of this message or its attachments is prohibited. If you have
received this communication in error, please notify the sender immediately
by telephone at 704.844.3100 and delete this message and all copies and
backups thereof. Thank you.
© 2020 Ensono, LP. All rights reserved. Ensono is a trademark of Ensono,
LP. The information contained in this communication is confidential, is
intended only for the use of the recipient named above, and may be legally
privileged. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution or copying of
this communication is strictly prohibited. If you have received this
communication in error, please resend this communication to the sender and
delete the original message or any copy of it from your computer system.
________________________________
CONFIDENTIALITY NOTICE: This e-mail message and all attachments may
contain legally privileged and confidential information intended solely
for the use of the addressee. If the reader of this message is not the
intended recipient, any reading, dissemination, distribution, copying, or
other use of this message or its attachments is prohibited. If you have
received this communication in error, please notify the sender immediately
by telephone at 704.844.3100 and delete this message and all copies and
backups thereof. Thank you.
© 2020 Ensono, LP. All rights reserved. Ensono is a trademark of Ensono,
LP. The information contained in this communication is confidential, is
intended only for the use of the recipient named above, and may be legally
privileged. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution or copying of
this communication is strictly prohibited. If you have received this
communication in error, please resend this communication to the sender and
delete the original message or any copy of it from your computer system.
This email originates from AXA Group Operations UK Ltd (reg. no. 1854856),
a company registered in England and Wales, which has its registered office
at 5 Old Broad Street, London EC2N 1AD, England.
This message and any files transmitted with it are confidential and
intended solely for the individual or entity to whom they are addressed.
If you have received this in error, you should not disseminate or copy
this email. Please notify the sender immediately and delete this email
from your system.
Please also note that any opinions presented in this email are solely
those of the author and do not necessarily represent those of the AXA
Group.
Email transmission cannot be guaranteed to be secure, or error free as
information could be intercepted, corrupted, lost, destroyed, late in
arriving or incomplete as a result of the transmission process. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of email transmission.
Finally, the recipient should check this email and any attachments for
viruses. The AXA Group accepts no liability for any damage caused by any
virus transmitted by this email.
This email originates from AXA Group Operations UK Ltd (reg. no. 1854856),
a company registered in England and Wales, which has its registered office
at 5 Old Broad Street, London EC2N 1AD, England.
This message and any files transmitted with it are confidential and
intended solely for the individual or entity to whom they are addressed.
If you have received this in error, you should not disseminate or copy
this email. Please notify the sender immediately and delete this email
from your system.
Please also note that any opinions presented in this email are solely
those of the author and do not necessarily represent those of the AXA
Group.
Email transmission cannot be guaranteed to be secure, or error free as
information could be intercepted, corrupted, lost, destroyed, late in
arriving or incomplete as a result of the transmission process. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of email transmission.
Finally, the recipient should check this email and any attachments for
viruses. The AXA Group accepts no liability for any damage caused by any
virus transmitted by this email.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic