PureConnect

 View Only
Discussion Thread View
  • 1.  provisioning server

    Posted 06-16-2020 16:52
    Hi All,

    We are going through a security audit and have been hit on a SSL cert issue. it is the cert used by provisioning server on port 8089, but i can't find any documentation that lets me know what cert that port uses. Since we are not getting dinged on port 8088, it looks like it will be a different cert.

    So my questions are:

    1 - can somebody point me to documentation about what cert is on port 8089 or let me know what cert it would used. I can almost guarantee it is the cert that came with the system and not a 3rd party cert we loaded.

    2- Point me in the right direction on how we can disable port 8089? We only use port 8088 disabling it would be another way we can get this issue resolved.

    Thank you,
     Scott
    #ArchitectureandDesign
    #PlatformAdministration
    #Security

    ------------------------------
    Scott Williams
    Missouri Higher Education Loan Authority
    ------------------------------


  • 2.  RE: provisioning server

    Posted 06-17-2020 09:34
    Scott - I think you can control inbound ports at your firewall (network; cisco) or locally you can control it using windows firewall. Inbound and outbound rules can be set for the local server. We go thru a PCI audit every year and I thought 8088 was the http port and 8089 was the https port for ???  Drawing a blank but I'll get with my engineer today who manages the audits and see if he can remember. I think it's that HTTPS cert you're looking for but can't remember all the use cases. For us, the web server <--> IC Server uses that particular cert.

    ------------------------------
    Dennis White
    Salelytics, LLC
    ------------------------------



  • 3.  RE: provisioning server

    Posted 06-17-2020 09:41
    Looks like I steered of course a bit. After reviewing the port map document, port 8089 is the https port for provisioning phones. 

    HTTP
    (Provision
    from Proxy)
    TCP 8088 /WAN HTTP
    (Provision
    from Proxy)
    TCP 8088 /WAN
    HTTPS
    (Provision
    from Proxy)
    TCP 8089 /WAN HTTPS
    (Provision
    from Proxy)
    TCP 8089 /WAN

    ------------------------------
    Dennis White
    Salelytics, LLC
    ------------------------------



  • 4.  RE: provisioning server

    Posted 01-28-2021 13:23
    Scott, did you happen to resolve your issue with SSL and 8089 for HTTPS provisioning of phones? We're running into an issue that port 8089 is showing an SSL 3.0 vulnerability and I'm not sure how to best mitigate it. We do use port 8089 and not 8088.

    We need to use only TLS 1.2 if at all possible but we definitely don't want to break the provisioning service.

    We have disabled SSL 2, SSL3 and TLS 1, TLS 1.1 at the OS level on our servers.

    Thanks,

    ------------------------------
    Shane
    SAIC
    ------------------------------



  • 5.  RE: provisioning server

    Posted 01-28-2021 14:22
    Edited by Scott Williams 01-28-2021 14:23
    Hi Shane,

    It seems these are tied to the line cert, so we had to update the Default Line Cert from using SHA1 to SHA256. This resolved our issue, but the a month later moved our system to a Single Cert configuration ( A big pain) to resolve other Security Findings having to do with the I3 system signing its own certificates.

    I am sure you will, but this change should be practiced/tested in Dev before trying to do in production, as we had to go through 3 different methods before one worked for us. One method we hit an SCR on, another method wasn't to change the default line cert and the finally the method that worked. Below is each method

    1. These are the instructions they sent to me to follow and is the process that worked for us. As we have CIC in switchover, I shut down the non-primary CIC server while running this and then brought it back up after the IC Service restart. I believe i went for a full reboot of the server(Always safer) vs just stopping and starting the Interaction Center Service, but either does the samething.
    1. It is recommended to do this after hours during a maintenance window as this will require a reboot of the server or just a restart of IC.
    2. Backup the Lines and LinesAuthority folders located in: (Drive IC is on) > I3 > IC > Certificates
    3. Delete the 2 before mentioned folder.
    4. Restart the entirety of IC (this was recommended by a development engineer I spoke with as just restarting admin server has the potential to cause inconsistencies in IC as the subsystems would be out of sync) **Full outage**
    5. Run your command gensslcertu.exe -l <line domain> -d -a SHA256
      1. The -d will set this new certificate as the default line cert
        Note: the default line cert will still just be named LinesCertificate in the folder, regardless of the domain name added in the command
        Note: you will not need to delete the entry in Administrator as this is just a pointer to the folder where the cert can be found.
    2. This is if the Line Cert is not using the default, ours was so this didn't work for us:
    1.  Create a backup of the line certificate       
    2. delete line certificate in IA (IA > System Configuration > Certificate Management > SIP/TLS Line Certificates Configuration > Line Certificates)
    3.  restart adminserver from IC System Manager
    4.  execute gensslcertu.exe -l <line domain> -a SHA256
    3. We were on 2019 R3 Patch 6 ( I believe) and hit SCR IC-155200 which prevented this method: 
    Update the Cert from the command line. This is the Syntax I built and they verified as correct  when it did not work. 

    GenSSLCertsU.exe -l (Line Cert name) -d -a sha256

    You can find the line cert name by going to System Configuration -->Certificate Management --> SIP/TLS Line Certificate Configuration


    GenSSLCertsU.exe [-l <CN Name or Domain Name> [-d] [-k <Key Size>] [-a <Signature Algorithm>] [-e]]

    • <CN Name>
      1. Lines certificate subject's common name
    • <Domain Name>
      1. Domain name for a DNS SRV record.
    • -d
      1. Make it the new Default Line certificate.
    • -k
      1. Specify key size. If this option is NOT specified, then the default key size used will be 2048 bits.
    • <Key Size>
      1. Key size in bits(e.g. 2048).
    • -a
      1. Specify signature algorithm to use. If this option is NOT specified, then SHA1 is used. NOTE: Some 3rd party applications may not be compatible with SHA-256 certificates.
    • <Signature Algorithm>
      1. Signature algorithm string ("sha1"|"sha256")
    • -e
      1. Create and sign new certificates with current keys if they exist. This allows changing the signature algorithm for existing certificates. If any certificates do not exist, this will fail.


    Hope this helps

    ------------------------------
    Scott Williams
    Missouri Higher Education Loan Authority
    ------------------------------



  • 6.  RE: provisioning server

    Posted 01-28-2021 14:32
    Awesome, thanks for the reply! We originally started out using SHA-256 but after initial setup we ran iMigrator and I guess we overlooked that it appeared to overwrite our SHA-256 with the SHA-1 from our previous IC servers. Bummer!

    We also have a switch pair and are 24x7 so as I understand we will take hard downtime during this process (obviously when the backup server is offline and the primary is rebooted).

    So I'll review this in detail. We also have the same vulnerability tickets for self-signed certificates for all of our servers. With that being said, would you recommend skipping the SHA-256 and going straight to a single cert configuration? I know you mentioned it was a big pain, so I'm not sure the best path to take here. Any suggestions or guidance if we go the self signed route?

    Thanks again.

    ------------------------------
    Shane
    SAIC
    ------------------------------



  • 7.  RE: provisioning server

    Posted 01-28-2021 15:16
    Edited by Scott Williams 01-28-2021 15:34
    Other then the outage, updating the Default Line Cert was relatively easy. The hardest part was getting the correct method and that only took a few weeks. So if you need to get some Vulnerabilities knocked out, this would be a fairly easy one.

    Moving to a single sign cert was a massive undertaking and took us 5 very long months. I found no clear documentation on how to do it so i followed the CIC setup guide, but it is vague and there was alot of steps missing, since it was written for a standpoint of new install and not an existing system.
     
    We actually had to do it twice, as we were told SIP Softphones wouldn't be affected by the change, but they were. So after we moved to a single sign cert we had to back completely out and then troubleshoot the SIP Softphone connect....Turns out there is a cert on the computer the SIP Softphone that is created the first time it connects to the CIC server that needs to be updated. So we had to create a cert, sign it and push it out to all our Computers.

    I am still working on our last issue that popped up after the Cert Change. Interaction Connect, which we are in the process of moving to broke, Luckily we don't have anybody using it yet so I just pushed forward with the Cert change. Our change was in October and have been working with Genesys Development trying to resolve the issue.

    I created an internal document so we had document on how to do this, since we will have to go through the process every 5 years as the cert expires. I will make a generic copy of it, removing my internal information, and send it to you so you can look it over. It might take me a few days, but should be able to get it to you early next week.

    ------------------------------
    Scott Williams
    Missouri Higher Education Loan Authority
    ------------------------------



Need Help finding something?

Check out the Genesys Knowledge Network - your all-in-one access point for Genesys resources