Jump to content

Mirek S.

ESET Staff
  • Content Count

  • Joined

  • Last visited

  • Days Won


Mirek S. last won the day on October 31 2018

Mirek S. had the most liked content!

Profile Information

  • Gender
  • Location
    Czech Rep.

Recent Profile Visitors

1,155 profile views
  1. I'm not aware of command line tool to edit policies, and policies are somewhat blackbox so supporting such tool would take some effort which isn't my decision to make. Please post suggestion into customer feedback or contact Your local customer care. HTH.
  2. There is ServerAPI which allows for some level of automation. I believe we have pythonian interface for it as well, however unsure if it's published (if you are interested in it I'll check with guys who created it if it's in stable enough state to be published). Last but not least there is customer feedback topic which is watched by PMs. HTH.
  3. Unsure we can solve this here, better option would be customer care ticket Some possible issues preventing new certificate being applied coming to mind. - connectivity between MDM management Agent and Server (policy was not applied) - you have some devices enrolled into MDM which causes previous certificate being still used. You can enforce immediate certificate switch via timeout in policy (next to HTTPS certificate upload in policy editor). Premature change could however break connectivity for devices which don't manage to update their trust settings with MDM server. What is possible is "-in" openssl argument of pkcs12 works differently across different openssl versions and didn't actually add chain (but only certificate). Please verify that there are 3 certificates printed out with "openssl pkcs12 -in yourpkcs12.pfx" HTH, M.
  4. Hello, Your chain is missing root CA - in this case it's "DST Root CA X3". https://www.identrust.com/dst-root-ca-x3 You can simply append it to your chain and convert to PFX again. For "simplicity" we decided both root CA and chain have to be in configured PKCS#12 (PFX) as most customers use ESMC generated certificates. This added some overhead for those who have their certificates signed by third party certification authorities as those usually don't include root CA (there is no reason to for them) in files they provide to their customers. HTH, M.
  5. Hello, Please upload fullchain.pem. I'll determine which root CA is missing (one vendor can have multiple CA) and write here step by step guide. M.
  6. Hello, MDC requires root CA certificate (and entire chain) within PFX file (Certificate authorities usually don't add their root CA). You'll need to convert PFX to PEM, append CA certificate to this PEM and convert it back to PFX. This is required due to fact we need to install root CA onto devices and we have no idea if there is pre-established trust. This changed on v7 where having root CA in windows certificate store was "good enough".
  7. It's actually "feature"... We had customers who reconfigured this and lost connectivity so this setting was removed around v 6.5
  8. Hello, You must go through the ESMC wizard which generates certificate signing request and private key one more time and use new files generated for Apple servers. Previous CSR was generated with expired vendor certificate. HTH, M.
  9. Hello, The issue is fixed on our backend now, please create new APNS/DEP certificate and retry the Apple signing process. Sorry for inconvenience. M.
  • Create New...