Do you have a reference source link for your statement: "You really shouldn't mix/combine the security of completely different services (thats what a certificate is - service identity) in a single certificate."
In a blog post of mine I want to link to your comment here but, also link to an official document/RFC.
Thanks a lot - and thanks heddi.nabbisen for this post!
Sorry about the delay, @bcjasond
.
It is a best practice. When you use the same certificate for different services, you directly couple their identity and the security assertions/claims of the certificate. i.e. what was certified by the CA in issuing the certificate, as described in the CA's Relying Party Agreement (or RPA).
In the example, as long as www and jabber are 1) on the same host infrastructure, and 2) have the same security context assured by the certificate, then you're ok. But the second they're jot identical, you can't separate them because they're bound together and you'll need new, separate certificates anyway.
So it's easier to manage them independently, so they can have different security policies and assurances appropriate to each service.
For example, the www service might need to have an EV certificate for e-commerce reasons, while the jabber service only needs a DV cert. Or they run in separate docker containers, so you would have to jave separate copies of the keypairs and certificate anyway, but because you've coupled them, any maintenance (e.g
cert replacement) on one MUST be performed on the other.
It doesn't scale and it doesn't leverage loose coupling when two unrelated systems inevitably diverge from each other, and it doesn't enable detection of a certificate issue when distinction between www and jabber services is required, because they are literally two names for the same identity. This is more critical when the example is an HA system and you want to know which host you are actually connecting to - you can't. e.g
www1 and www2 are SANS in the same cert.
In closing, its not something you would find in a standard, but in your security policy in support of best practices, including clear identity assignment and infrastructure implementation specifications.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Dear MichaelKing1832
Thank you for your description and follow-up.
I'm so grateful to you 🙂
I'll learn and get experienced much more...
Hey MichaelKing1832,
Do you have a reference source link for your statement: "You really shouldn't mix/combine the security of completely different services (thats what a certificate is - service identity) in a single certificate."
In a blog post of mine I want to link to your comment here but, also link to an official document/RFC.
Thanks a lot - and thanks heddi.nabbisen for this post!
Sorry about the delay, @bcjasond .
It is a best practice. When you use the same certificate for different services, you directly couple their identity and the security assertions/claims of the certificate. i.e. what was certified by the CA in issuing the certificate, as described in the CA's Relying Party Agreement (or RPA).
In the example, as long as www and jabber are 1) on the same host infrastructure, and 2) have the same security context assured by the certificate, then you're ok. But the second they're jot identical, you can't separate them because they're bound together and you'll need new, separate certificates anyway.
So it's easier to manage them independently, so they can have different security policies and assurances appropriate to each service.
For example, the www service might need to have an EV certificate for e-commerce reasons, while the jabber service only needs a DV cert. Or they run in separate docker containers, so you would have to jave separate copies of the keypairs and certificate anyway, but because you've coupled them, any maintenance (e.g
cert replacement) on one MUST be performed on the other.
It doesn't scale and it doesn't leverage loose coupling when two unrelated systems inevitably diverge from each other, and it doesn't enable detection of a certificate issue when distinction between www and jabber services is required, because they are literally two names for the same identity. This is more critical when the example is an HA system and you want to know which host you are actually connecting to - you can't. e.g
www1 and www2 are SANS in the same cert.
In closing, its not something you would find in a standard, but in your security policy in support of best practices, including clear identity assignment and infrastructure implementation specifications.