IT Management Suite

 View Only
  • 1.  securing the SMP to HTTPs question

    Posted Apr 04, 2021 03:01 AM
    Hi Experts.

    why when securing the SMP to https port 443, does the UNIX and linux agent download path remains on "http" URL and not "https" ?
    is it something that can be changed, or is it intentionally remains like this?
    http://ITMS.com/Altiris/NS/NSCap/Bin/Unix/AgentInstall/Linux/x64/aex-bootstrap-linux

    thanks,

    Hagai


  • 2.  RE: securing the SMP to HTTPs question

    Posted Apr 19, 2021 11:59 AM
    Any one?


  • 3.  RE: securing the SMP to HTTPs question

    Posted Apr 28, 2021 10:21 AM
    Any One?

    For some reason after securing the SMP to 443, the windows link and path for agent has changed successfully to "https:......", but for some reason the path for the UNIX targets is still only "http", why is that? is there any additional configuration required? 

    tnx,

    Hagai


  • 4.  RE: securing the SMP to HTTPs question

    Posted Apr 29, 2021 08:34 AM
    Are you saying if you enter the HTTPS link it doesn't work?  I can't imagine why that would be.  Are are you trying to do a push to the Unix agents from the console and then they automatically hit the HTTP link?  If the latter, you could use some other method to initiate the install rather than a push like include an agent install step in your server build process.  I think that method is most common.  Another option would be to use a redirect rule to automatically re-route HTTP requests for certain pages on the NS to the HTTPS equivalent.   I did this for the console pages and for the software portal because both of those were having issues from Chrome when using HTTP.

    ------------------------------
    Joe
    ------------------------------



  • 5.  RE: securing the SMP to HTTPs question

    Posted Apr 29, 2021 08:39 AM
    hi Joe,
    that is exacatly what I am saying. but the NS console is set only for port443 and https, meaning the installation is set not to work with http, and yet somehow (only in Unix targets) if i use HTTPS is fails, and if I use HTTP, it works.

    dont know what configuration i am missing, since the the https web page and the unix web page all get to the same address which is HTTPS:\\nsconsole...... 

    any ideas?

    tnx,

    Hagai


  • 6.  RE: securing the SMP to HTTPs question

    Posted Apr 29, 2021 09:21 AM
    What error do you get when you try the HTTPS URL?  My guess is your SMP SSL cert is not trusted by your Unix host and you'll want to add the appropriate cert to the trusted root store.  If the error you get is not SSL related, please share the details / screen shot.  If its some server error, check the SMP event logs from the time when you get the error.

    ------------------------------
    Joe
    ------------------------------



  • 7.  RE: securing the SMP to HTTPs question

    Posted Apr 29, 2021 10:42 AM
    Hi Joe!
    That is precisely the error code I'm getting!!!
    but I've added the needed certs (otherwise the server wouldn't have accepted them).

    my NS is closed to http, only the IIS for the download link (aex-bootstrap-linux) is on http webpage, but the certs are a must.

    these are the same certs I installing on the windows targets and they are working great.

    that's the weird thing. if i check the certs in the Linux target , they exist and successfully installed (prior to the agent push).
    certs installed:

    Https:

    Http:
    any ideas where i am missing something? 

    tnx,

    Hagai


  • 8.  RE: securing the SMP to HTTPs question

    Posted Apr 29, 2021 11:58 AM
    I don't have Linux or Mac agents reporting to my NS so I have no direct experience here.  I notice the error recognizes that the cert is self-signed.  It doesn't say it's not trusted, it says it could not be verified.  My guess is this means the download step is attempting to determine if the certificate has been revoked.  This is normally done by looking for a certificate revocation list from the certificate authority (CA).  I'm not a cryptology expert I'm guessing such an action is not possible on a self-signed certificate.  Possible solutions:
    1) As the error suggests, include the --no-check-certificate option in the HTTP get for the package
    2) Replace the SMP cert with one from a public CA ($) or a trusted internal CA
    3) Deliver the package to the machine via some other method.  For example, you could generate an offline CEM agent package and include it in the OS build.  An extra advantage of this method is the CEM gateway configuration and certs are included which would allow machines to register on the NS from external networks.  We have done this for years and it has been very useful during this pandemic to be able to ship new laptops direct from the OEM factory to users with our build applied then our automated build process installs and activates Altiris without them needing to connect to the internal network.

    ------------------------------
    Joe
    ------------------------------



  • 9.  RE: securing the SMP to HTTPs question

    Posted Apr 29, 2021 12:54 PM
    Hi Joe,
    I will check these suggestions.

    tnx,

    Hagai


  • 10.  RE: securing the SMP to HTTPs question

    Broadcom Employee
    Posted Apr 30, 2021 03:02 AM
    If "Default Web SIte" has "Use SSL" disabled, then URL to download ULM Agent will be http
    (If "Use SSL" will be enabled, then URL to download ULM Agent will be https)

    1. Check what profile is set to ULM Agent installation from pic above (Make sure that all required certificates are in Default NS communication profile)
    2. Check what setting are set in "Install XML" tab of "Installation Settings" dialog (If settings are OK and there is Certificate data set, you can re-created ULM installation package just click "save" button in "Installation Settings" dialog.
    3. Probably when you switched to HTTPs and set new certificate in IIS for "Default Web Site" :443 port, previously generated ULM Agent installation packages have wrong certificate.
    4. Does Common Name of your NS Server is correctly resolved by Linux client? I mean that in your self-signed certificate there should be CN= like hostname or fqdn of your NS server machine but if Linux resolves it by hostname but in self-signed certificate there is only FQDN CName of NS, then it will fails.


    ------------------------------
    Software QA Engineer
    Broadcom Inc.
    ------------------------------