7 Replies Latest reply on Jun 19, 2017 11:31 AM by Lisa Keeler

    Updating HTTPS Certificate

    Jeff Sikorski

      ADDM Version 11.1 patch 5

       

      I'm trying to update my HTTPS Certificate.  When I upload the certificate file, I don't get any error message, and in fact I know something kind of good happened because it says:

      Server CertificateOK Certificate expires in over a year

       

      However, I'm not able to see the new certificate view Chrome, IE, Firefox, etc.  It's still referencing the old one.  Even if I run curl on the site, it gives me back the old certificate. 


      I have tried re-starting all tideway services.

       

      I turned on debug for User Interface and re-uploaded the certificate...

       

      I'm not sure if this info message is normal ..  this is the only thing in the log that looked interesting.  I'm a little hesitant to go in the appliance and copy the crt from 1 place to another.  I will probably raise a ticket with BMC Support on this.  I was just curious if anyone else had similar problems when replacing the HTTPS certificates and had any suggestions?

       

      I would assume the https admin page is pretty straightforward:
      You upload a certificate ... either it's a bad certificate and you get an error, or it's a good certificate and you are done.

       

      140594716108544: 2017-06-16 16:16:29,617: ui.web.sso.webauth.rsasecurid: DEBUG: WEBAUTH_RSASECURID_ENABLED: Check option

      140594716108544: 2017-06-16 16:16:29,617: ui.web.sso.webauth.rsasecurid: DEBUG: WEBAUTH_RSASECURID_ENABLED disabled

      140594716108544: 2017-06-16 16:16:29,617: security.api: DEBUG: Create new validator for 'security/https/admin'

      140594716108544: 2017-06-16 16:16:29,662: api.https: INFO: Files /usr/tideway/etc/https/server.crt /etc/httpd/conf/ssl.crt/server.crt don't match

      140594716108544: 2017-06-16 16:16:29,683: api.https: INFO: Files /usr/tideway/etc/https/ca-bundle.crt /etc/httpd/conf/ssl.crt/ca-bundle.crt don't match

      140594716108544: 2017-06-16 16:16:29,686: api.audit: DEBUG: log user event : https_config_change

      140594716108544: 2017-06-16 16:16:29,687: api.audit: DEBUG: Log user audit event https_config_change : {'machine_name': 'mybox', 'certificate': 'New Server Certificate Uploaded', 'user_groups': 'public, system', 'certificate_before': 'Overwritten', 'full_name': 'ADDM System User', 'msg': 'User system changed HTTPS configuration', 'event_group': 'Appliance Confi'}

      140594716108544: 2017-06-16 16:16:29,687: api.audit: DEBUG: Logging event https_config_change to log UserEvent

      140594716108544: 2017-06-16 16:16:29,698: api.audit: DEBUG: event https_config_change logged successfully to UserEvent

      140594705618688: 2017-06-16 16:16:29,774: ui.web.sso.webauth.rsasecurid: DEBUG: WEBAUTH_RSASECURID_ENABLED: Check option

      140594705618688: 2017-06-16 16:16:29,775: ui.web.sso.webauth.rsasecurid: DEBUG: WEBAUTH_RSASECURID_ENABLED disabled

      140594705618688: 2017-06-16 16:16:29,775: security.api: DEBUG: Create new validator for 'security/https/admin'

      140594705618688: 2017-06-16 16:16:29,783: common.edition.settings: DEBUG: Checking enable_external_api for edition ENTERPRISE

      140594705618688: 2017-06-16 16:16:29,783: common.edition.settings: DEBUG: Not restricted.

      140594705618688: 2017-06-16 16:16:29,784: security.api: DEBUG: Create new validator for 'security/https/admin'

      140594705618688: 2017-06-16 16:16:29,832: api.https: INFO: Files /usr/tideway/etc/https/server.crt /etc/httpd/conf/ssl.crt/server.crt don't match

      140594705618688: 2017-06-16 16:16:29,854: api.https: INFO: Files /usr/tideway/etc/https/ca-bundle.crt /etc/httpd/conf/ssl.crt/ca-bundle.crt don't match

      140594705618688: 2017-06-16 16:16:29,856: common.edition.settings: DEBUG: Checking enable_external_api for edition ENTERPRISE

      140594705618688: 2017-06-16 16:16:29,856: common.edition.settings: DEBUG: Not restricted.

       

      Thanks!
      Jeff

        • 1. Re: Updating HTTPS Certificate
          Jeff Sikorski

          [root@xxxxxx https]# pwd

          /usr/tideway/etc/https

          [root@xxxxxx https]# ls -tl

          total 44

          -rw-rw-r-- 1 tideway tideway 5962 Jun 16 16:19 ca-bundle.crt

          -rw-rw-r-- 1 tideway tideway 1868 Jun 16 16:16 server.crt

          -rw-rw-r-- 1 tideway tideway 1868 Jun 16 14:16 server.crt.bak

          -rw-rw-r-- 1 tideway tideway 5962 Jun 16 11:55 ca-bundle.crt.bak

          -rw-r--r-- 1 tideway tideway 9972 Jun  5 15:57 openssl.conf

          -rw-rw-r-- 1 tideway tideway  993 Oct  4  2016 server.csr

          -rw-rw---- 1 tideway tideway 1679 Oct  4  2016 server.key

           

           

           

          this is in the ssl.crt directory inside /etc/httpd/conf .. which still has my old server.crt and ca-bundle.crt from last October .. which are the "old ones" i'm trying to replace.

           

          [root@xxxxxx ssl.crt]# pwd

          /etc/httpd/conf/ssl.crt

          [root@xxxxx ssl.crt]# ls -tl

          total 12

          -rw-r--r-- 1 root root 5763 Oct  4  2016 ca-bundle.crt

          -rw-r--r-- 1 root root 1698 Oct  4  2016 server.crt

          • 2. Re: Updating HTTPS Certificate
            Jeff Sikorski

            should i change the ownership of ca-bundle.crt and server.crt over to tideway from root?  Not sure why they are owned by root, but I'm sure that might be part of the reason why the new ones can't copy over?

            • 3. Re: Updating HTTPS Certificate
              Andrew Waters

              Try pressing "Configure" and in that dialog "Apply"

              • 4. Re: Updating HTTPS Certificate
                Jeff Sikorski

                Didn't think to test that and see what happened..

                 

                I am generating the certificate from openSSL .. so there is no way the Key and certificate would match right?

                 

                The reason why I'm doing openSSL is so i can create the cert with a SAN.  The latest Google Chrome throws an error(warning) for certificates that don't contain a SAN... and eventually the warning will turn to an error.  Since I can't generate the certificate via the Web UI with a SAN, I need to use openSSL.

                 

                ss1.png

                • 5. Re: Updating HTTPS Certificate
                  Andrew Waters

                  Without knowing specifically what you have done I cannot answer that. There is nothing to stop you creating and signing a certificate using the generated key.

                  • 6. Re: Updating HTTPS Certificate
                    Jeff Sikorski

                    There's a KA for it on BMC's support site:
                    ARTICLE NUMBER 000129702

                     

                    Basically -- if you go the route I went, you really just need to do it all manually on the Linux appliance itself and forget about trying to use the Web UI.


                    Copy the crt's and key and override

                    /etc/httpd/conf/ssl.crt/ca-bundle.crt

                    /etc/httpd/conf/ssl.crt/server.crt

                    /etc/httpd/conf/ssl.key/server.key

                     

                    and do a service httpd restart.

                     

                    I do hope BMC considers this in future releases and allows it through the Web UI... that Google Chrome is soon to be ignoring certs with just Common Name:

                     

                    https://www.thesslstore.com/blog/security-changes-in-chrome-58/

                     

                    Common Name Support Removed:

                    Many people don’t know that the “Common Name” field of an SSL certificate, which contains the domain name the certificate is valid for, was actually phased-out via RFC nearly two decades ago. Instead, the SAN (Subject Alternative Name) field is the proper place to list the domain(s).

                    However, this has been ignored and for many years the Common Name field was exclusively used. Chrome is finally fed up with the field that refuses to die. In Chrome 58, the Common Name field is now ignored entirely.

                    This means certificates that were exclusively using that field to indicate the valid domain name are no longer supported. Publicly-trusted SSL certificates have been supporting both fields for years, ensuring maximum compatibility with all software – so you have nothing to worry about if your certificate came from a trusted CA.

                    This change will only affect private PKIs and other software that have not been following spec. If you notice any sites returning the error “NET::ERR_CERT_COMMON_NAME_INVALID,” it’s likely due to the certificate not using SANs properly. Users of products like Sophos’ HTTPS interception are now finding out that their software is not RFC-compliant. Eric Lawrence wrote more about this topic.

                    An enterprise policy has been added for those who need Common Name support for a while longer.

                    Recent research by Netflix has shown that Common Name handling can be exploited, demonstrating that this is one of the important security changes in Chrome 58