I have stood up a new smgr/sm 7.1. Before moving on to the SBC I just wanted to test the equinox mobile app directly to SM to make sure it works. At just a basic level I just need to create a new SIP user. I exported the identity and trust certs from SM and SMGR and I keep getting cert errors. Would those not work by manually installing them on the mobile device?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Equinox 4
- Thread starter wpetilli
- Start date
-
1
- #2
ios or android? I think there's a part in iOS where it doesn't let apps hit the OS's trusted store and sandboxes them to a per app certificate store and Android might just let you install in "trusted root CAs" like windows does.
traceSM at R7 has a TLS handshake trace where you can see what certs are offered by either end. Do you have mutual TLS authentication enabled where SM is expecting a cert offered by Equinox that SMGR signed? Might need to use the SMGR CA to make a cert for "all my equinox users" and import that to the equivalent of the "personal" store
traceSM at R7 has a TLS handshake trace where you can see what certs are offered by either end. Do you have mutual TLS authentication enabled where SM is expecting a cert offered by Equinox that SMGR signed? Might need to use the SMGR CA to make a cert for "all my equinox users" and import that to the equivalent of the "personal" store
- Thread starter
- #3
hmm. you can still initTM -f on SM7 to force SM to offer the demo cert, but in the absence of that, SM offers the "mySM.mydomain.com" cert signed by SMGR. Might need to import the SMGRCA cert into the same Equinox client so it trusts not just "stuff signed by Avaya out of the box" but also "stuff signed by your SMGR"
They were saying they were going to forbid SM from offering demo certs at all, but that was met with some backlash considering noone ever got the security stuff sorted out. So, initTM -f and kill your SM for a half hour, or traceSM with TLS validation to see if SM is offering a cert signed by your SMGR, and if so, import that CA cert to equinox.
They were saying they were going to forbid SM from offering demo certs at all, but that was met with some backlash considering noone ever got the security stuff sorted out. So, initTM -f and kill your SM for a half hour, or traceSM with TLS validation to see if SM is offering a cert signed by your SMGR, and if so, import that CA cert to equinox.
jimbojimbo
Vendor
Equinox supports two different modes for certificates. It will either use the OS store or a Private Store. Once you have one certificate in the private store the private store is used exclusively. For internal CA I suggest using the private store. Put the CA certificates on your HTTP server in PEM format and set the TRUSTCERTS value in the 46xxsettings.txt file to include your certs. NOTE: IP Phones only store up to 6 CA certs so be aware of this limitation when adding additional certificates. Your device should now download the certificates when you configure Equinox (either through e-mail or url). You can see the downloaded trusted certificates in the Equinox Settings on the device. When using the Private Trust store you need to provide the CA certficates for all services so if you want to use Exchange integration you need the Exchange CA cert(s).
- Thread starter
- #6
I'm still having struggles with this. At a very basic level, before testing externally via the SBC I just wanted to get the IOS client registered directly to SM internally. I started out with certificate errors, which I believe I sorted. I exported from SMGR/SM and installed manually on the device. Those errors stopped and I'm now getting VoIP phone service Unavailable. On the client end I'm manually configuring the client and putting in the IP of the Security module, port 5061/tls and my domain. Then just entering the 4 digit extension and security code. When I run a traceSM I see the client/server exchange messages and aren't seeing any errors. I get a load of appdata exchanges between the sm100 and the mobile client. The only noticeable message I see is a Fault from the sm100 to the mobile client, which reads:
SOAP-ENV:Fault xmlns:SOAP-ENV=" |
22:2| <faultcode>SOAP-ENV:Server.generalException</faultcode>
22:2| <faultstring>DataNotAvailable</faultstring> |22:2| <detail>
22:2| <Fault> |
22:2| <Fault> |
22:2| <PPMMethod>getHomeCapabilities</PPMMethod> |
22:2| <fault>DataNotAvailable</fault> |
22:2| <usePPMFault>true</usePPMFault> |
22:2| </Fault> |
22:2| <exceptionName>com.avaya.ccs.ppm.domain.PPMOperationFault</exceptionName> |
22:2| </Fault> |
22:2| </detail> |
22:2|</SOAP-ENV:Fault>
Not sure where this comes into play. What am I missing?
SOAP-ENV:Fault xmlns:SOAP-ENV=" |
22:2| <faultcode>SOAP-ENV:Server.generalException</faultcode>
22:2| <faultstring>DataNotAvailable</faultstring> |22:2| <detail>
22:2| <Fault> |
22:2| <Fault> |
22:2| <PPMMethod>getHomeCapabilities</PPMMethod> |
22:2| <fault>DataNotAvailable</fault> |
22:2| <usePPMFault>true</usePPMFault> |
22:2| </Fault> |
22:2| <exceptionName>com.avaya.ccs.ppm.domain.PPMOperationFault</exceptionName> |
22:2| </Fault> |
22:2| </detail> |
22:2|</SOAP-ENV:Fault>
Not sure where this comes into play. What am I missing?
restart mgmt in the SM CLI kicks the PPM service. I've had to do it once around 6.3.4ish and isn't service affecting. Can't remember if phones were getting empty PPM or if it was cause it was just not responding.
But yeah, I can't imagine why SM would have empty profile data. Does a 9600SIP phone acquire the same empty PPM?
But yeah, I can't imagine why SM would have empty profile data. Does a 9600SIP phone acquire the same empty PPM?
- Thread starter
- #8
- Thread starter
- #9
-
1
- Thread starter
- #10
- Thread starter
- #12
My A/D team doesn't want to deploy any new certs to our managed mobile devices since they already have our company certs on them. They would rather cut certs from our internal CA to install on the Avaya Servers. Is there an easy to follow process of the steps to do this? There's tons of documentation about certs, but of course nothing that spells out what needs to be done.
Eesh. No dice there man. Got to go through making SMGR a sub-CA of the windows domain so everything you do with SMGR chains up to the Windows CA.
No way around that. You need "identity certs" offered by SM that are from a CA your devices trust.
Either it's 3rd party everything and the domain guys sign all your server certs, or they let SMGR be a sub-CA so it's allowed to sign certs that still chain up to the Windows domain CA.
Last choice, is if it's all through the SBC, you can just deal with the SBC offering the "mysbc" cert signed by the Windows CA and have the SBC re-wrap all the TLS to the Aura core with the SMGR domain certs. That's how you do the reverse proxy stuff for aura conferencing. To say, the godaddy public cert for "yourconferenceserver" is offered by the SBC and the SBC wnwraps that and rewraps it with a cert signed by SMGR towards "yourconferenceserver"
So, if you got all your Avaya endpoints internal/anything that goes direct to SM under your control and you can send them your SMGR CA cert as an authority they trust, and the mobile stuff is always through the SBC (as in, on corportate wifi sessionmanager.you.com resolves to the public IP and not the private one) you might be able to get away with just the SBC chaining up to the Windows domain CA.
No way around that. You need "identity certs" offered by SM that are from a CA your devices trust.
Either it's 3rd party everything and the domain guys sign all your server certs, or they let SMGR be a sub-CA so it's allowed to sign certs that still chain up to the Windows domain CA.
Last choice, is if it's all through the SBC, you can just deal with the SBC offering the "mysbc" cert signed by the Windows CA and have the SBC re-wrap all the TLS to the Aura core with the SMGR domain certs. That's how you do the reverse proxy stuff for aura conferencing. To say, the godaddy public cert for "yourconferenceserver" is offered by the SBC and the SBC wnwraps that and rewraps it with a cert signed by SMGR towards "yourconferenceserver"
So, if you got all your Avaya endpoints internal/anything that goes direct to SM under your control and you can send them your SMGR CA cert as an authority they trust, and the mobile stuff is always through the SBC (as in, on corportate wifi sessionmanager.you.com resolves to the public IP and not the private one) you might be able to get away with just the SBC chaining up to the Windows domain CA.
- Thread starter
- #14
They're not willing to make SMGR as a subCA, so what they've done is:
1. replaced/installed a new identity cert in SM against the security module SIP service cut from our PKI
2. added our root/subca certs in the SMGR trust store for TM_Outbound/Inbound TLS
2.a --- this broke the SIP trunks to CM --
3. installed the root/subca certs on CM in the trusted cert store.
--- trunks came back---
Still have some more tests to do, but this is the path they want to go down.
1. replaced/installed a new identity cert in SM against the security module SIP service cut from our PKI
2. added our root/subca certs in the SMGR trust store for TM_Outbound/Inbound TLS
2.a --- this broke the SIP trunks to CM --
3. installed the root/subca certs on CM in the trusted cert store.
--- trunks came back---
Still have some more tests to do, but this is the path they want to go down.
Ouch! So, I believe at 7.1 CM/SM do mutual TLS authentication even if it's turned off in SM. Haven't bothered looking at CM to see if I can make it not offer a cert to SM.
To say, with mutual TLS auth off in SM and just doing initTM, my TLS handshake in SM showed CM failed with an unknown CA error on the cert SM offered CM.
Once I let CM trust the SMGR CA cert, CM accepted the SM cert offered and then still offered up it's default cert that SM then rejected. So, I signed a cert in SMGR for CM and wrapped it up as a PKCS12 with private key and once CM user that, I got my TLS up.
That's the nasty thing about security. You don't have the luxury of defining how stringent you can be on any given box. So say CM, if TLS, requires two way TLS regardless, any box like it may need a PKCS12 cert with private key to speak to SM.
Can SM have an identity cert it offers from 1 CA and SMGR sign the CM cert and negotiate two way TLS with certs each endpoint trusts despite being from different CAs? Good question!
If not, can SM not validate CN or subjectAltDN in a cert so you can have 1 Windows domain cert for "myAvayaboxes" that CM/AAM/Anythingelse can offer SM to trust?
Without knowing what your network looks like - say, college campus style wifi with thousands of mobile devices on net vs workplace and going through the SBC cause they're off-net, you'd still need to reconcile any remote worker scenario and with the SBC as 1 neck to choke it might just be worth it to force all mobile through the SBC for simplicity's sake. Do your mobile devices absolutely need to speak direct to SM?
I honestly had no idea that you could load another domain's CA cert to SMGR to trust and use that other domain to sign SM's identity cert and have them trust one another. Seriously, that's gold! I guess I kind of answered my previous question of "can 2 boxes offer certs from different domains so long as both trust both CAs that issued them". Honestly, that sounds like the best compromise. Not 3rd party everything, not SMGR as a sub-CA but having the required apps trusting/having certs from another domain but they keep their hands off of SMGR's CA that does other types of enrollment for things for their management links. I hope it works out for you! Please let us know!
To say, with mutual TLS auth off in SM and just doing initTM, my TLS handshake in SM showed CM failed with an unknown CA error on the cert SM offered CM.
Once I let CM trust the SMGR CA cert, CM accepted the SM cert offered and then still offered up it's default cert that SM then rejected. So, I signed a cert in SMGR for CM and wrapped it up as a PKCS12 with private key and once CM user that, I got my TLS up.
That's the nasty thing about security. You don't have the luxury of defining how stringent you can be on any given box. So say CM, if TLS, requires two way TLS regardless, any box like it may need a PKCS12 cert with private key to speak to SM.
Can SM have an identity cert it offers from 1 CA and SMGR sign the CM cert and negotiate two way TLS with certs each endpoint trusts despite being from different CAs? Good question!
If not, can SM not validate CN or subjectAltDN in a cert so you can have 1 Windows domain cert for "myAvayaboxes" that CM/AAM/Anythingelse can offer SM to trust?
Without knowing what your network looks like - say, college campus style wifi with thousands of mobile devices on net vs workplace and going through the SBC cause they're off-net, you'd still need to reconcile any remote worker scenario and with the SBC as 1 neck to choke it might just be worth it to force all mobile through the SBC for simplicity's sake. Do your mobile devices absolutely need to speak direct to SM?
I honestly had no idea that you could load another domain's CA cert to SMGR to trust and use that other domain to sign SM's identity cert and have them trust one another. Seriously, that's gold! I guess I kind of answered my previous question of "can 2 boxes offer certs from different domains so long as both trust both CAs that issued them". Honestly, that sounds like the best compromise. Not 3rd party everything, not SMGR as a sub-CA but having the required apps trusting/having certs from another domain but they keep their hands off of SMGR's CA that does other types of enrollment for things for their management links. I hope it works out for you! Please let us know!
- Thread starter
- #16
Honestly, anything regarding certs is foreign to me. Up until this initiative with mobility and SMGR/SM7.x I never had to worry about it. Aside from AES because they've managed that due to LYNC/OCS.
What's also interesting is this CM that I uploaded these new certs onto (keeping in mind I removed the SMGR cert from it) and got the trunks back in-service to the SM7.x cluster.. I also created an SIP entity and entity link of this same CM to a totally different SMGR/SM 6.x cluster, which use the original AVAYA certs and those trunks were also in-service at the same time. Trying to figure how that's possible.
In our case we'll only be rolling out the mobile app to select folks and not firmwide. They definitely want to leverage DNS for when the folks are external it will resolve to the SBC and if internal directly to SM. I'm literally right in the middle of the SBC config so I haven't even got to what needs to be installed on those. I'm assuming the same root/subca certs, but will see what happens.
What's also interesting is this CM that I uploaded these new certs onto (keeping in mind I removed the SMGR cert from it) and got the trunks back in-service to the SM7.x cluster.. I also created an SIP entity and entity link of this same CM to a totally different SMGR/SM 6.x cluster, which use the original AVAYA certs and those trunks were also in-service at the same time. Trying to figure how that's possible.
In our case we'll only be rolling out the mobile app to select folks and not firmwide. They definitely want to leverage DNS for when the folks are external it will resolve to the SBC and if internal directly to SM. I'm literally right in the middle of the SBC config so I haven't even got to what needs to be installed on those. I'm assuming the same root/subca certs, but will see what happens.
Ok. I suppose it might actually be impossible to make CM ignore the default Avaya SIP CA. It might let you delete them, but under the hood, I don't know if it can be explicitly ripped out. Remember - save translations/reset system 4 anytime you want to see those cert changes from the webpage take effect.
Yeah, the SBC is a monumental pain and the documentation is poor and it lets you administer yourself into a black hole. This is to say if the "name" of the cert profile isn't the short hostname of the CN of the cert, it doesn't actually work. Now , the SBC won't tell you that. It'll happily administer what you told it and always offer the default Avaya SBC Edge Cert it shipped with and you'll pull yuor hair out trying to figure that out.
But all that aside, depending on device capacity, maybe you can just resolve mobileclients.you.com to the SBC regardless of whether they're inside or out. Maybe you'll get everything to work, but regardless, you know you'll be supporting them coming in through the SBC anyway. Capacity aside, it would make it apples and apples regardless of how they get in. Agreeably, not the best solution if you're a university campus with 3000 mobile wifi devices, but it lets you have 1 outside interface just for them, with the cert in question that is isolated from the rest of your environment. If B1 has 1 IP for your carrier IP trunks and 1 for these guys, you're just changing that single point of entry when you need to change things and I like it that it's tidy.
I totally understand the domain security guys don't want to bend to a particular stack you manage and send your certs to everyone, but its looking like you're getting the exact opposite pressure to tailor to their requirements in every facet of your environment. This is what SBCs are for! They reconcile NAT, sure. They hide topologies, fine. But they can also be your certificate juggler and/or reconciler of security stuff between different domains so you just manage the in and out of the SBC to SMGR and the Windows CA and leverage that. You're going to be doing it anyway, I'd make a gentle push to try to make all of it that way.
Yeah, the SBC is a monumental pain and the documentation is poor and it lets you administer yourself into a black hole. This is to say if the "name" of the cert profile isn't the short hostname of the CN of the cert, it doesn't actually work. Now , the SBC won't tell you that. It'll happily administer what you told it and always offer the default Avaya SBC Edge Cert it shipped with and you'll pull yuor hair out trying to figure that out.
But all that aside, depending on device capacity, maybe you can just resolve mobileclients.you.com to the SBC regardless of whether they're inside or out. Maybe you'll get everything to work, but regardless, you know you'll be supporting them coming in through the SBC anyway. Capacity aside, it would make it apples and apples regardless of how they get in. Agreeably, not the best solution if you're a university campus with 3000 mobile wifi devices, but it lets you have 1 outside interface just for them, with the cert in question that is isolated from the rest of your environment. If B1 has 1 IP for your carrier IP trunks and 1 for these guys, you're just changing that single point of entry when you need to change things and I like it that it's tidy.
I totally understand the domain security guys don't want to bend to a particular stack you manage and send your certs to everyone, but its looking like you're getting the exact opposite pressure to tailor to their requirements in every facet of your environment. This is what SBCs are for! They reconcile NAT, sure. They hide topologies, fine. But they can also be your certificate juggler and/or reconciler of security stuff between different domains so you just manage the in and out of the SBC to SMGR and the Windows CA and leverage that. You're going to be doing it anyway, I'd make a gentle push to try to make all of it that way.
- Thread starter
- #18
Each leg of this seems to be getting more and more complicated.. Regarding the SBC H/A pair:
1. Do both servers essentially share the A and B interface IP addresses? Once primary goes offline the secondary takes those IP's? I'm guessing that's the case since both server interfaces show the same IP addresses when I do 'ip address' from the CLI.
2. For the Equinox mobile app server address, what's the best way to handle that.. via fqdn or IP?
3. For the SBC certificates,,,,am I installing our Root/SubCA certs that are already on our mobile devices and an identity cert for the SBC itself?
1. Do both servers essentially share the A and B interface IP addresses? Once primary goes offline the secondary takes those IP's? I'm guessing that's the case since both server interfaces show the same IP addresses when I do 'ip address' from the CLI.
2. For the Equinox mobile app server address, what's the best way to handle that.. via fqdn or IP?
3. For the SBC certificates,,,,am I installing our Root/SubCA certs that are already on our mobile devices and an identity cert for the SBC itself?
-
2
- #19
1.Yes. In a active/standby config, not active/active.
2.FQDN. The old way for a browser or SIP client to validate a server's cert was ensuring the CN of the cert = the FQDN. Current way is to make sure that FQDN is in the subjectAltName. Ctrl+F "RFC 2818" in a 46xxettings file.
What that means is if you use IP on Equinox, and say, put the SMGR CA cert in the client so it trusts certs offered by SM signed by SMGR (or the Windows CA, it doesn't matter) the Equinox client will reject it if subjectAltName does not match what you put as the server in the client. IP in client, FQDN in cert - or vice versa = TLS failure. That's to say you may trust the issuer of the cert, but not the entity presenting it to you. That's like me stealing your driver's license and giving it to a cop. Yes, it's a real license issued by your state DMV, but the ugly dude handing it to the cop looks nothing like the guy's picture on the license.
You can add both IP+fqdn as multiple subjectAltNames to mitigate that.
3. The SBC, as a "server" must offer a certificate the clients trust. So, sbccert.com signed by the Windows DC is fine. It can ALSO do mutual TLS authentication requiring a cert to be offered from the client asking for service. SM can as well - there's a tickbox called Mutual TLS Authentication in SM Administration. In the SBC, under TLS management, in client and server profiles, you have peer verification. If enabled, then the client must offer a cert signed by a CA that the SBC trusts. Also, when you're doing that, the cert installed on the client must be in a format that includes the private key. The client will offer the public key of that cert to the SBC, the SBC will be cool with that because it trusts the CA that signed it, but the client still needs the private key of the cert to be able to be able to decipher the SBCs response. All of that private key PKCS12 stuff happens in the background for, say, a SM when you initTM to enroll it to System Manager.
The very nature of PKI makes it so that the CA signing your cert has no idea what your private key happens to be. I can make a key pair, sign a csr with it (so that it may only be decrypted by the PUBLIC key), then SMGR or a Windows CA open it with the public key offered and sign it. Once signed, that public key is in the cert, but the CA never had any idea what the associated private key was. Only the generator of the key is in control of that. If that cert ever needs to be used to be presented to authenticate identity, the presenter of that certificate must be able to prove ownership of the private key. He does that by proving he successfully decoded a message from the other guy that was encrypted with the public key.
To have your Equinox or anything else do that, it needs a PCKS12.
Here's a quick tutorial:
On any linux box with openssl:
openssl genrsa -des3 -out test.key 2048
You'll make a passphrase for your key. Anything is fine.
openssl req -new -key test.key -out test.csr
Before it continues, you'll need to enter the passphrase entered in the step below to prove it's your key. Don't enter a password in the final step when it wraps up. Not the same thing.
You can use a period as a blank to not fill in any fields you don't want to. To be honest, they're all pretty much optional because the template in the CA can re-assign them. Also, the default fields openssl will ask for don't necessarily include the extra fields you need like subjectAltName anyway.
Now, toss test.csr into your CA - either copy/paste, send the file, whatever, and sign the cert. Put that test.crt in the same folder as test.key and test.csr.
openssl pkcs12 -export -out test.pfx -inkey test.key -in test.crt
Enter the passphrase for your key again and test.pfx is now a PKCS12 cert you can give to an app to prove to a server you're trusted.
You may need to add "-certfile CACert.crt" at the end - though I don't have to when SMGR signs because it includes the validation chain. That's to say what comes out of SMGR's CA is a cert called test that includes the SMGR CA cert. If your CA doesn't do that, you'll need the -certfile switch.
I know it's convoluted. But here's why it matters:
When establishing one way or two way TLS - who is trying to prove they're trustworthy?
When I go to my bank's website or when someone sends me a link to join a Webex, I'm John Q Public the client and they're the server that wants my personal information - that could be my debit card number or access to my PCs webcam and microphone. I have nothing to prove who I am and they'd better prove to me they're worth giving my personal information to.
When your user has an Equinox client and they need a TLS session to send a SIP REGISTER message, you WILL need to prove to them you're trustworthy just like the bank's website does and because of the nature of the server, you may darn well want them to prove they have more than just a username and password but also a security document you can verify was issued by you. That's why mutual TLS authentcation matters and you use PKCS12s to prove that.
Without it, equinox.you.com is publically resolvable. Odds are that the SBC will offer it's cert signed by your domain with the whole validation chain (to say, your SMGR or Windows domain CA cert). I wireshark my handshake to you, see it fail, capture your CA cert and tell my PC to trust it. Now, I can try registering to you with a username and password.
If your TLS is only 1 way - and the only one way it can be is for the server to prove trustworthiness, not the client. Then I, as a malicious client, may decide to trust you. Now you will process my login attempts and maybe I'll get lucky on the guy who's password is 1234.
It took me a while to get my head around this stuff and this is the simplest I think I can explain it. I wish I could have had the benefit of someone spelling things out this way because I'd have caught on a lot sooner. That being the case, ask questions if anything I said wasn't clear.
2.FQDN. The old way for a browser or SIP client to validate a server's cert was ensuring the CN of the cert = the FQDN. Current way is to make sure that FQDN is in the subjectAltName. Ctrl+F "RFC 2818" in a 46xxettings file.
Code:
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.What that means is if you use IP on Equinox, and say, put the SMGR CA cert in the client so it trusts certs offered by SM signed by SMGR (or the Windows CA, it doesn't matter) the Equinox client will reject it if subjectAltName does not match what you put as the server in the client. IP in client, FQDN in cert - or vice versa = TLS failure. That's to say you may trust the issuer of the cert, but not the entity presenting it to you. That's like me stealing your driver's license and giving it to a cop. Yes, it's a real license issued by your state DMV, but the ugly dude handing it to the cop looks nothing like the guy's picture on the license.
You can add both IP+fqdn as multiple subjectAltNames to mitigate that.
3. The SBC, as a "server" must offer a certificate the clients trust. So, sbccert.com signed by the Windows DC is fine. It can ALSO do mutual TLS authentication requiring a cert to be offered from the client asking for service. SM can as well - there's a tickbox called Mutual TLS Authentication in SM Administration. In the SBC, under TLS management, in client and server profiles, you have peer verification. If enabled, then the client must offer a cert signed by a CA that the SBC trusts. Also, when you're doing that, the cert installed on the client must be in a format that includes the private key. The client will offer the public key of that cert to the SBC, the SBC will be cool with that because it trusts the CA that signed it, but the client still needs the private key of the cert to be able to be able to decipher the SBCs response. All of that private key PKCS12 stuff happens in the background for, say, a SM when you initTM to enroll it to System Manager.
The very nature of PKI makes it so that the CA signing your cert has no idea what your private key happens to be. I can make a key pair, sign a csr with it (so that it may only be decrypted by the PUBLIC key), then SMGR or a Windows CA open it with the public key offered and sign it. Once signed, that public key is in the cert, but the CA never had any idea what the associated private key was. Only the generator of the key is in control of that. If that cert ever needs to be used to be presented to authenticate identity, the presenter of that certificate must be able to prove ownership of the private key. He does that by proving he successfully decoded a message from the other guy that was encrypted with the public key.
To have your Equinox or anything else do that, it needs a PCKS12.
Here's a quick tutorial:
On any linux box with openssl:
openssl genrsa -des3 -out test.key 2048
You'll make a passphrase for your key. Anything is fine.
openssl req -new -key test.key -out test.csr
Before it continues, you'll need to enter the passphrase entered in the step below to prove it's your key. Don't enter a password in the final step when it wraps up. Not the same thing.
You can use a period as a blank to not fill in any fields you don't want to. To be honest, they're all pretty much optional because the template in the CA can re-assign them. Also, the default fields openssl will ask for don't necessarily include the extra fields you need like subjectAltName anyway.
Now, toss test.csr into your CA - either copy/paste, send the file, whatever, and sign the cert. Put that test.crt in the same folder as test.key and test.csr.
openssl pkcs12 -export -out test.pfx -inkey test.key -in test.crt
Enter the passphrase for your key again and test.pfx is now a PKCS12 cert you can give to an app to prove to a server you're trusted.
You may need to add "-certfile CACert.crt" at the end - though I don't have to when SMGR signs because it includes the validation chain. That's to say what comes out of SMGR's CA is a cert called test that includes the SMGR CA cert. If your CA doesn't do that, you'll need the -certfile switch.
I know it's convoluted. But here's why it matters:
When establishing one way or two way TLS - who is trying to prove they're trustworthy?
When I go to my bank's website or when someone sends me a link to join a Webex, I'm John Q Public the client and they're the server that wants my personal information - that could be my debit card number or access to my PCs webcam and microphone. I have nothing to prove who I am and they'd better prove to me they're worth giving my personal information to.
When your user has an Equinox client and they need a TLS session to send a SIP REGISTER message, you WILL need to prove to them you're trustworthy just like the bank's website does and because of the nature of the server, you may darn well want them to prove they have more than just a username and password but also a security document you can verify was issued by you. That's why mutual TLS authentcation matters and you use PKCS12s to prove that.
Without it, equinox.you.com is publically resolvable. Odds are that the SBC will offer it's cert signed by your domain with the whole validation chain (to say, your SMGR or Windows domain CA cert). I wireshark my handshake to you, see it fail, capture your CA cert and tell my PC to trust it. Now, I can try registering to you with a username and password.
If your TLS is only 1 way - and the only one way it can be is for the server to prove trustworthiness, not the client. Then I, as a malicious client, may decide to trust you. Now you will process my login attempts and maybe I'll get lucky on the guy who's password is 1234.
It took me a while to get my head around this stuff and this is the simplest I think I can explain it. I wish I could have had the benefit of someone spelling things out this way because I'd have caught on a lot sooner. That being the case, ask questions if anything I said wasn't clear.
- Thread starter
- #20
- Status
Similar threads