| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| CA signing with same dn |
« View previous topic :: View next topic » |
| Author |
Message
|
| pintrader |
 Posted: Tue Oct 14, 2014 2:33 am Post subject: CA signing with same dn |
 |
|
Disciple
Joined: 22 Jan 2014
Posts: 164
|
hi
I have a server A, and server B
On server A, I did a CSR with -dn = "mydomain.com,O=blah1,OU=blah2,L=blah3,C=blah4". Then its signed with a CA such as entrust. I perform the adding of the necessary certs into MQ and is working fine.
However, now I create a new keystore on server B, and use the same label and -dn (used for server A) for creating the CSR. After signing with the same CA, i added the root/chain certs and its ok. however when i try to receive the server cert i encounter error :
| Code: |
| CTGSK3009W One or more certificates in the keystore could not be loaded. |
Is it due to using the same -dn and label? what could be the problem? thanks |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Oct 14, 2014 5:51 am Post subject: Re: CA signing with same dn |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| pintrader wrote: |
| Is it due to using the same -dn and label? |
Yes. Why would 2 certs ever legitimately have the same dn and label? Given that dn is an abbreviation of Distinguished Name, why did you think they didn't need to distingush the 2 certs? Given the label is how the certs are retrieved from the store (like laundry labels in a dry cleaners) why did you think they didn't need to be unique?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| pintrader |
| Posted: Tue Oct 14, 2014 3:22 pm Post subject: Re: CA signing with same dn |
|
|
Disciple
Joined: 22 Jan 2014
Posts: 164
|
| Vitor wrote: |
| pintrader wrote: |
| Is it due to using the same -dn and label? |
Yes. Why would 2 certs ever legitimately have the same dn and label? Given that dn is an abbreviation of Distinguished Name, why did you think they didn't need to distingush the 2 certs? Given the label is how the certs are retrieved from the store (like laundry labels in a dry cleaners) why did you think they didn't need to be unique? |
hi thanks, so in a way, if I have a UAT environment set up, i cannot just bring the keystore over to a production and use it. I must create another CSR with a different label and dn? however, can my labels be the same because I have given same QMGR name to UAT and production. thanks |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Oct 14, 2014 11:15 pm Post subject: Re: CA signing with same dn |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| pintrader wrote: |
| hi thanks, so in a way, if I have a UAT environment set up, i cannot just bring the keystore over to a production and use it... |
Nothing to stop you doing that - sites have been cloning client key stores since the dawn of SSL and IBM MQ - but not advisable.
| pintrader wrote: |
| ...I must create another CSR with a different label and dn?... |
Why would you not want to ensure separation of UAT and Production by ensuring the DN is unique to each queue manager, e.g. by the CN value?
| pintrader wrote: |
| ...however, can my labels be the same because I have given same QMGR name to UAT and production. thanks |
Your labels can be whatever you want them to be, they're effectively a free-form field, however, that does not mean the queue manager will be able to make use of the certificate unless you're on IBM MQ V8.0, and (IMHO) it's not a good idea to 'duplicate' queue managers as it can lead to all sorts of head-scratching at times, or disaster where clustering (MQ-style) is used.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 15, 2014 5:13 am Post subject: Re: CA signing with same dn |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| pintrader wrote: |
| hi thanks, so in a way, if I have a UAT environment set up, i cannot just bring the keystore over to a production and use it. |
That's a bad idea, as it means the SSL is not separating UAT & Prod. Your auditors may have a view.
| pintrader wrote: |
| I have given same QMGR name to UAT and production. |
Certificates notwithstanding this is a very, very bad idea. You should not have identically named queue managers in your estate. Aside from the possible confusion (UAT changes being accidentally applied to Prod), if you ever want to use a MQ cluster your job will be much, much harder.
Best practice is to have separately named queue managers hosting identically named objects in (your example) UAT & Prod.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Wed Oct 15, 2014 5:15 am Post subject: Re: CA signing with same dn |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1231
Location: Gold Coast of Florida, USA
|
| pintrader wrote: |
| ...I have given same QMGR name to UAT and production. thanks |
Do yourself a giant favor and uniquely name each and every Qmgr in your network (which is a "Best Practice"). Also for SSL that goes with the Qmgr, make the CN=<QmgrName> which will aid in SSLPEER filtering. If you are using Internal CAs (which is nothing more than a self signed certificate used to sign CSRs), make one for PROD and a different one for non-PROD. This will make it impossible to connect non-PROD with PROD (also a "Best Practice"). |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 15, 2014 7:39 am Post subject: Re: CA signing with same dn |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| JosephGramig wrote: |
| Do yourself a giant favor and uniquely name each and every Qmgr in your network (which is a "Best Practice"). Also for SSL that goes with the Qmgr, make the CN=<QmgrName> which will aid in SSLPEER filtering. If you are using Internal CAs (which is nothing more than a self signed certificate used to sign CSRs), make one for PROD and a different one for non-PROD. This will make it impossible to connect non-PROD with PROD (also a "Best Practice"). |
Impossible I think not. Will it require a deliberate effort? Certainly! 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Wed Oct 15, 2014 8:50 am Post subject: Re: CA signing with same dn |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1231
Location: Gold Coast of Florida, USA
|
| fjb_saper wrote: |
| JosephGramig wrote: |
| Do yourself a giant favor and uniquely name each and every Qmgr in your network (which is a "Best Practice"). Also for SSL that goes with the Qmgr, make the CN=<QmgrName> which will aid in SSLPEER filtering. If you are using Internal CAs (which is nothing more than a self signed certificate used to sign CSRs), make one for PROD and a different one for non-PROD. This will make it impossible to connect non-PROD with PROD (also a "Best Practice"). |
Impossible I think not. Will it require a deliberate effort? Certainly! |
Well, starting with a naming standard would help...
Like QmgrName with the following pattern:
ABBBCNM
Where:
A is P=PROD,U=UAT,T=TEST,D=DEV
BBB is Application code or department (ARD for accounts receivable department)
C is A for application use, R for Full Repositor, G for Gateway, B for IIB
N is 0..9 for Horizontal scaling (multiple Qmgrs in a cluster on different boxes doing load balancing)
M is 0..9 for Vertical scaling (multiple Qmgrs in a cluster on the same box doing load balancing)
For example: PARDA00 would be PROD accounts receivable department's application Qmgr of just one.
Keep QmgrNames to 9 or less characters because the names are best used in channels FromQmgr.ToQmgr and channels have a 20 character length.
Or just name them after dead rock stars. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
