This blog speaks about using Entrust as Certificate Authority for iOS device enrollments using Afaria MDM. SAP officially announced the support of Entrust CA with Afaria 7.0 SP08 onwards. We implemented this solution for a Energy Utility company, before and since SAP Afaria officially supported Entrust CA.
Afaria connects to two type of Entrust CA products available in market. They are Entrust Admin Services and Entrust Self Service Module with Identity Guard Services. We in our landscape used the second method of connection i.e. Entrust Self Service Module with Identity Guard Services.
Following are the different method that we can configure Certificate Authority Type in Afaria 7.0 SP08 onwards.
CA Type: Entrust uses Entrust Admin Services for certificate generation
CA Type: SCEP uses Entrust Self Service Module with Identity Guard Services.
Though using Entrust Admin Services is optimal method for CA configuration, in this blog we are going to see about configuration using Entrust Self Service Module (SSM) with Identity Guard Services (IDG). Entrust SSM and Entrust IDG product are installed and configured separately on Windows Servers. These Entrust products use DB2 as database for to store Entrust data and certificate data. Entrust IDG connects to Entrust CA cloud to generate the certificate and return it back to Afaria and enrolling device.
When SCEP CA Type is used, Afaria creates SCEP requests which is compatible with Microsoft CA. As this is using a different path for the request as designed in IG, there has been introduced an IIS to rewrite incoming request. This IIS rewrite is taken care by Entrust SSM SCEP Servlet. Entrust SSM takes care of converting the IIS request to Tomcat request and sends then request to Entrust IDG to generate certificate.
The request will look like from Afaria to Entrust SSM as
http://:8020/certsrv/mscep/mscep.dll
This rewrites internally in Entrust SSM as
http://:80/igscep
The above details are the standard configuration, so as to get device enrollment successful. But later in version SP12 above of Afaria 7.0, to enable further security the SCEP request from Afaria is more complex and therefore longer. With the increased size of the SCEP request the IIS has failed to process the rewriting. With the increased size of the SCEP request the IIS has failed to process the rewriting.
This is causing bigger issue of device not enrolling return SCEP error, while profile generation and also some already enrolled device not able to connect to Afaria Server.
This is because Tomcat 7 does not have the rewrite valve, as this is a new feature introduced with Tomcat 8. Tomcat 7 comes along with Entrust SSM installation and thus the problem. To resolve this issue, there is a rewrite open source project for older tomcats, which works with Tomcat 7 shipped with SSM. Details can be found in the link http://tuckey.org/urlrewrite.
Steps to do:
1. Enable crossContext to allow proxy action from ROOT to IGSCEP: Tomcat/conf/Context.xml
<Context useHttpOnly="false" crossContext="true">
2. Create root folder under Tomcat/webapps
3. Place the urlrewrite jar file in the new root folder
4. Restart SSM tomcat service.
IIS port 8020: http://<idgssmhost>:8020/certsrv/mscep/mscep.dll
Tomcat Port 80 - old: http://<idgssmhost>:80/igscep
Tomcat Port 80 - new: http://<idgssmhost>:80/certsrv/mscep/mscep.dll
Kindly provide me your feedback or comment.
Thanks.
Afaria connects to two type of Entrust CA products available in market. They are Entrust Admin Services and Entrust Self Service Module with Identity Guard Services. We in our landscape used the second method of connection i.e. Entrust Self Service Module with Identity Guard Services.
Following are the different method that we can configure Certificate Authority Type in Afaria 7.0 SP08 onwards.
CA Type: Entrust uses Entrust Admin Services for certificate generation
CA Type: SCEP uses Entrust Self Service Module with Identity Guard Services.
Though using Entrust Admin Services is optimal method for CA configuration, in this blog we are going to see about configuration using Entrust Self Service Module (SSM) with Identity Guard Services (IDG). Entrust SSM and Entrust IDG product are installed and configured separately on Windows Servers. These Entrust products use DB2 as database for to store Entrust data and certificate data. Entrust IDG connects to Entrust CA cloud to generate the certificate and return it back to Afaria and enrolling device.
When SCEP CA Type is used, Afaria creates SCEP requests which is compatible with Microsoft CA. As this is using a different path for the request as designed in IG, there has been introduced an IIS to rewrite incoming request. This IIS rewrite is taken care by Entrust SSM SCEP Servlet. Entrust SSM takes care of converting the IIS request to Tomcat request and sends then request to Entrust IDG to generate certificate.
The request will look like from Afaria to Entrust SSM as
http://:8020/certsrv/mscep/mscep.dll
This rewrites internally in Entrust SSM as
http://:80/igscep
The above details are the standard configuration, so as to get device enrollment successful. But later in version SP12 above of Afaria 7.0, to enable further security the SCEP request from Afaria is more complex and therefore longer. With the increased size of the SCEP request the IIS has failed to process the rewriting. With the increased size of the SCEP request the IIS has failed to process the rewriting.
This is causing bigger issue of device not enrolling return SCEP error, while profile generation and also some already enrolled device not able to connect to Afaria Server.
This is because Tomcat 7 does not have the rewrite valve, as this is a new feature introduced with Tomcat 8. Tomcat 7 comes along with Entrust SSM installation and thus the problem. To resolve this issue, there is a rewrite open source project for older tomcats, which works with Tomcat 7 shipped with SSM. Details can be found in the link http://tuckey.org/urlrewrite.
<filter>
<filter-name>UrlRewriteFilter</filter-name>
<filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>UrlRewriteFilter</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>Steps to do:
1. Enable crossContext to allow proxy action from ROOT to IGSCEP: Tomcat/conf/Context.xml
<Context useHttpOnly="false" crossContext="true">
2. Create root folder under Tomcat/webapps
3. Place the urlrewrite jar file in the new root folder
4. Restart SSM tomcat service.
IIS port 8020: http://<idgssmhost>:8020/certsrv/mscep/mscep.dll
Tomcat Port 80 - old: http://<idgssmhost>:80/igscep
Tomcat Port 80 - new: http://<idgssmhost>:80/certsrv/mscep/mscep.dll
Kindly provide me your feedback or comment.
Thanks.
- SAP Managed Tags:
