Understanding DHCP Option 43

May 21, 2012 by · 23 Comments 

Although not the first on this topic this article does contain a more comprehensive and detailed explanation of exactly how Option 43 is formatted and utilized, and is designed to assist in the configuration of any third-party DHCP service which supports the vendor-specific Option 43.  The following articles and documentation are all suggested reading when dealing with configuring Option 43 for use with Lync Server 2010 deployments.

Note that DHCP Option 120 will not be discussed specifically in this article but the concepts covered do apply to the formatting and usage of Option 120 in the same way.  This is an industry standard SIP server option (see RFC 3361) which is not vendor specific and simply advertises the IP address or the Fully Qualified Domain Name (FQDN) of the SIP Registrar dedicated to handling registration requests for clients and devices on the network.  Lync Server specifically requires that the parameter is an FQDN as TLS connectivity requires the use of domain names (IP addresses are not supported by Lync for this option).


Lync Server 2010 introduced the usage of DHCP Option 43 which is used to provide clients and devices on a network the ability to locate the Lync Server’s Certificate Provisioning service, and thus automatically download a certificate required to support secure HTTPS and TLS communications for the remainder of the session. Typically this new Option 43 is equated to the PIN Authentication feature provided in the Lync Phone Edition client written for the Aries family of devices, but it is not used solely for that purpose.  For example other qualified clients and devices can use this option to download the Root certificate even if PIN Authentication is not supported on that specific client.

Previously the only way a device or client could download a root certificate in order to trust the issuing CA of an OCS Registrar was by leveraging LDAP access to Active Directory.  When an Enterprise Windows CA is deployed the root certificate (and any issuing subordinate CAs certificates in the chain) are automatically placed into Active Directory and thus any domain-joined workstations will automatically have been provisioned the certificate(s) and the trust would already have been established. Also non-domain joined systems can leverage LDAP access to AD to download these CA certificate(s) as well.  In the case that a Standalone Windows CA is deployed then the certificate(s) are not placed into AD by default and must be done so manually.  Anyone who has ever attempted to get a Tanjay device to work on Office Communications Server on a network where a Windows Enterprise Certificate Authority was not deployed should be familiar with the process of manually importing Root (and possibly subordinate) CA certificates into Active Directory.

But with Lync Server there is now the CertProv web service included on the Front End (and Director) server which can facilitate the process of handing out any subordinate and/or root CA certificates.  The addition of DHCP Option 43 allows native Lync clients and any other Lync qualified devices or clients which are aware of this option the ability to perform this automatic provisioning process to build a secure TLS connection with the server and move on to registration and authentication steps.  In the LDAP process the older clients can query an LDAP server (Active Directory in this case) for the Certification Authority objectCategory and then be passed the root certificate.

Certificate Download

Now to take a peak at the Certificate Provisioning process provided by the Lync Web Services.  During the initial provisioning the client utilizes DHCP Option 43 to identify the full URL of the Certificate Provisioning service and opens a clear-text HTTP 80 connection to the web server.  This is the reason that Lync Phone Edition devices must be able to connect to the internal Lync web services over port 80 as well as 443.  (When a device is external the root certificate should already be trusted as in almost all cases the Access Edge Service should be equipped with a trusted public certificate.)

In the HTTP 200 OK response the message contains the entire Root CA certificate in PKCS #7 Base-64 format.


To validate that the provided certificate is actually the correct certificate the chain data can be decoded and verified using a few simple steps.  (As Wireshark is used in this example then these steps to export the raw data are specific to that application, but other network capture utilities also provide their own methods for copying or exporting the raw text.)

  • Highlight the certificate data in the bottom window as shown in the previous screenshot and then select File > Export > Selected Packet Bytes and then save the file.

  • Open the saved file in a text editor and select and copy the entire string.
  • Paste the string into a certificate decoder (e.g. http://certlogik.com/decoder) and decode the data.  Notice that the Issuer and Subject fields should be the same value, indicating that this is a self-signed certificate.  It was issued by a certificate authority as inferred by the inclusion of the description “RootCA”’ in the Common Name.


Disassembling Option 43

A few of the related articles provided at the beginning were created to specifically address how to configure DHCP services which are not Windows DHCP, but they do not go into the deeper level of detail to explain the formatting of the parameters.  Understanding this clearly is key to formatting the information correctly for use with any type of DHCP service.  Since Option 43 is actually comprised of multiple sub-options some systems might ask for the individual parameters separately during configuration while other systems may require all values to be concatenated into a single string.  As each value is appended with a header to provide option and parameters length details it can be difficult to properly configure.

The first step is to fine out what the exact values are for a specific Lync Server deployment.

  • From the Windows Command Prompt on the Lync Front End Server execute the DHCPUtil utility with the following switches to simply print out to the screen the resulting sub-option parameters required by the Lync Server.  The SipServer parameter should be defined as the FQDN of the Lync Front End Server.

“%ProgramFiles%\Common Files\Microsoft Lync Server 2010\DHCPUtil.exe” -SipServer  lync.schertz.local


Executing the above command will not impact any current DHCP configuration so it is safe to perform this simply to view the required parameters even if it has already been configured and is only being run as a learning exercise to follow along with this article.

If multiple Lync servers are deployed in the environment then the SipServer parameter may need to be defined as a Lync Pool FQDN (in the case of an Enterprise Edition deployment).  Additionally if any load balancing is configured on the Front End pool and the Internal Web Services FQDN is different than the Pool FQDN (in the case of DNS Load Balancing) then an additional switch of WebServer needs to be used to provide the Web Services FQDN.  If the WebServer swtich is not provided the command uses the SipServer value by default for both the registrar and web services location.

Additionally if a Director Server or Pool is in place then the Director FQDN is typically defined as the SipServer parameter (and the WebServer parameter is not needed).

The following table captures the output from the utility including the hexadecimal strings for each sub-option.

Sub-Option Sub-Option Name Hexadecimal Value
1 UC Identifier 4D532D55432D436C69656E74
2 URL Scheme 6874747073
3 Web Server FQDN 6C796E632E7363686572747A2E6C6F63616C
4 Port 343433
5 Relative Path for Certificate Provisioning Web Service 2F4365727450726F762F4365727450726F766


To understand what these values actually represent then the strings should be converted from hexadecimal to ASCII text.  Sub-Option 2 will be used in this example as it is a simple string which should be identical in every deployment..

  • Reformat the hexadecimal value in groupings of two digits to facilitate easier reading of the string and to highlight the fact that each set of digits is part is a single hexadecimal value.  So this 10-character string is actually 5 unique hexadecimal values.

6874747073 = 68:74:74:70:73

  • Using an ASCII character chart locate the hexadecimal value of the first grouping (e.g. “68”) and identify the resulting ASCII character for that value (e.g. “h”).


  • Look up the remaining hexadecimal values in the string to convert the entire string into a readable ASCII string.


68 = h
74 = t
74 = t
70 = p
73 = s

  • So the output hexadecimal string of “6874747073” converted to ASCII is “https” which defines the URL Scheme.

Clearly this process could take considerable time to piece together the remaining sub-option values, so how that the process is understood a convertor can be used on the other values.

  • By utilizing a Hex to ASCII Converter each sub-option string can be quickly decoded into plain English one at a time.


The resulting conversions should look nearly identical to the examples below, with traditionally only sub-option 3 being different as it should match the unique Lync Server FQDN in the specific environment.  Technically it is possible for sub-options 2, 4, and 5 to be different than the examples but rarely if ever are the defaults changed for the Lync certificate provisioning service URL, port, or security type values.

4D532D55432D436C69656E74 = “MS-UC-Client”

6874747073= “https”

6C796E632E7363686572747A2E6C6F63616C= “lync.schertz.local”

343433 = “443”

2F4365727450726F762F4365727450726F766973696F6E696E67536572766963652E737663 = “/CertProv/CertProvisioningService.svc”

An important concept to understand is that every single ASCII character is represented by a unique two-digit hexadecimal code, so if a specific hexadecimal string happens to be 24 characters long (e.g. “4D532D55432D436C69656E74”) then the actual ASCII string would be exactly half of that value, or 12 characters (e.g. “MS-UC-Client”).  The importance of this will become clear in a later step when these values are concatenated into a single string.

To see the configuration in action the following trace shows the data provided by the DHCP server in a reply to the client’s INFORM request with each of the sub-options listed under VendorSpecificInformation – Type 43.


The highlighted text is the entire set of DHCP parameters concatenated in a single string complete with header information.  Both the hexadecimal and ASCII data is listed in the

2B 5A 01 0C 4D 53 2D 55 43 2D 43 6C 69 65 6E 74 02 05 68 74 74 70 73 03 12 6C 79 6E 63 2E 73 63 68 65 72 74 7A 2E 6C 6F 63 61 6C 04 03 34 34 33 05 25 2F 43 65 72 74 50 72 6F 76 2F 43 65 72 74 50 72 6F 76 69 73 69 6F 6E 69 6E 67 53 65 72 76 69 63 65 2E 73 76 63 DC 03 4E 41 50


Taking a closer look at the hexadecimal string the individual sub-option strings can be identified with additional data in between each value.  Each sub-option is represented by a grouping which includes a 2-bit header.

  • The first value in the header highlighted in green indicates the Sub-Option (e.g. 0x01)
  • The second value highlighted in orange indicates the Length of the sub-options value (e.g. 0x0C = 12)
  • The third value highlighted in yellow is the Parameter Value  itself (e.g. 4D532D55432D436C69656E74)

2B 5A 01 0C 4D 53 2D 55 43 2D 43 6C 69 65 6E 74 02 05 68 74 74 70 73 03 12 6C 79 6E 63 2E 73 63 68 65 72 74 7A 2E 6C 6F 63 61 6C 04 03 34 34 33 05 25 2F 43 65 72 74 50 72 6F 76 2F 43 65 72 74 50 72 6F 76 69 73 69 6F 6E 69 6E 67 53 65 72 76 69 63 65 2E 73 76 63 DC 03 4E 41 50

As previously mentioned the Length is actually the amount of individual ASCII digits, or individual hexadecimal values which are represented by pairs of digits.  So either count the number of hexadecimal groupings or simply divide the total number of characters by two; either approach will result the in the correct value for the parameter’s length.

4D532D55432D436C69656E74 = 24 characters / 2 = 12 hexadecimal values

4D:53:2D:55:43:2D:43:6C:69:65:6E:74 = 12 hexadecimal values

12 decimal = 0C hexadecimal

And as noted before only sub-option 3 will typically be different between Lync Server environments, so when setting the values manually for any third-party DHCP server solution make sure to pay close attention to the length as the Web Server FQDN will vary between deployments.  The rest of the sub-options should match the example above exactly.

As for the few unmentioned values at the beginning and end of the captured string the leading 2B and 5A values represent the DHCP Option number of 43 (2B hexadecimal = 43 decimal) and the length of the entire Vendor Specific parameter (5A hexadecimal = 90 decimal).  And the trailing data (DC 03 4E 41 50) is part of Sub-Option 220 which defines DHCP NAP information and is unrelated to Lync.

It should now be quite evident that if the proper Length value is not defined when setting these parameters then clients would be unable to properly locate the beginning and end of each sub-option’s data string, and devices would fail to locate the Certificate Provisioning web service.

About Jeff Schertz
Site Administrator


23 Responses to “Understanding DHCP Option 43”
  1. Derek says:

    More comprehensive detail is an understatement! :-) But I wouldn't expect any less from you! Great article!

  2. Amr says:

    Hello Jeff,
    I was reading this part "Additionally if a Director Server or Pool is in place then the Director FQDN is typically defined as the SipServer parameter (and the WebServer parameter is not needed)." and I though "correct me if I'm wrong" that there is also another case which is if an SBA is in place at a branch site, then the SBA FQDN will be the SipServer and the the Central site Pool will be the WebServer?

    • jeffschertz says:

      Amr, that is correct. I didn't go into all of the potential configuration scenarios, but SBS/SBA is a common example worth pointing out. The SBS/SBA component only includes a SIP registrar (the Option 120 target) but does not host any web services (the Option 43 target).

  3. Frank says:

    Jeff, Do we need to add every Lync pool into DHCP eg. when adding new 2013 pools to an existing 2010 deployment? Thanks!

    • jeffschertz says:

      No, only a single pool can be defined per DHCP server or scope configuration, so you'll define a 'master' pool to handle initial queries from clients utilizing DHCP 43/120. If the user account is in another pool then the server will redirect the client accordingly.

  4. mcitp says:

    I’ve read a few good stuff here. Definitely worth bookmarking for revisiting. I wonder how much effort you put to make any such excellent informative site.

  5. Philip says:

    Hey Jeff, we setup DHCP option 43 awhile back. I think our IP 5000s are not pulling the correct certificate from the provisioning server. Some of the phones are populating an Application CA 6 certificate from a Certificate Authority server, which does not match the thumbprint/cert I put in manually in the Application CA 1 field using an XML config. I have yet to get anywhere with Polycom support and our eight IP 5000s are still freezing at random. I think TLS might be the issue, just a hunch.

    • jeffschertz says:

      The certificate you see in the CA-6 slot is the one downloaded directly from the Lync server and the same that would be supplied to Lync Phone Edition devices. In that event you typically would not be manually importing any certificates into the other slots.

      • Philip says:

        Thank you Jeff. We are at 8 months of trying to figure this one out. Tech support did find this error 0731105232|sip |4|03|TLS-DSK: Setting of Client Certificate failed due to (336445449) error:140DC009:SSL routines:SSL_CTX_use_certificate_chain_file:PEM lib Any ideas on this error?

        I checked the option 43 settings, and did find and fix a few problems, but the phone still froze overnight. Is there an easy way to confirm the CA-6 rootCA cert is valid? (we have 8 ip5000 phones in our environment doing the same thing, CX models work fine)

        • Philip says:

          Jeff, we finally made some progress with Polycom support on our IP 5000 freezing issue, ticket 1-400565141. According to their engineering team, the phone initially uses NTLM to authenticate. After receiving the certificate, it then tries to switch over to the TLS DSK method, which for some unknown reason is failing. Until they determine a long term fix, disabling TLS DSK by adding voIpProt.SIP.tlsDsk.enable="0" has worked for us. They also mentioned other customers having this issue. Just wanted to pass it along to others. Thanks.

  6. Hey Jeff, do you know if it is safe to use DHCPUtil.exe if option 43 is already in use by other services and configured in DHCP? A customer of ours is using it for SCCM I believe they said, and I am worried that running the script may delete these existing records. I had a look at the batch file and it appears safe.

    • Jeff Schertz says:

      If they are in fact overlapping then if you run the script it will delete and recreate those options. If you have to support multiple simultaneous SIP platforms then you made need to utilize VLANs to separate the devices and thus provide different DHCP scopes to them.

  7. Chris Lehr says:


    Feel free to post a link to my blog for Option 120 traffic. I spent some time on this today and tried to do my best to make it very clear.


    Regards, hope all is well!

  8. MarkHe says:

    Hi Jeff,
    actually I´ve got a problem with length of option 43 hex , it`s 182 characters long, Cisco supports only 180 Characters :-(

    FQDN can´t be changed, hope you´ve a solution.

  9. Stefano says:

    Hi Jeff,
    As far I know the certificate download (HTTP) is no longer used in the new firmware.
    Because of that I’m running the following problem:

    Let’s pretend this scenario:
    domain: lab.local
    User: user
    UPN: user@lab.com

    If I use the UPN authentication (USB tethering) the phone doesn’t try to download the certificate on port 80 anymore, and it tries to identify any available DC using the domain lab.com. Phone performs the query for the _ldap._tcp.dc._msdcs.lab.com and then _ldap._tcp.dc._msdcs.lab.com.lab.local. Both DNS query fail because there’s no LDAP SRV for the public domain and the second doesn’t exist (malformed).
    The only workaround I see, is signing-in using the DOMAIN\user and then switch to UPN.

    I need the UPN login because I have a mailbox on O365 and I have to use the UPN auth in order to be able to sign-in.
    Do you see any workaround? Any suggestion?


Check out what others are saying about this post...
  1. […] DHCP Option 43 : Jeff Schertz’s Blog Posted on May 21, 2012 by johnacook http://blog.schertz.name/2012/05/understanding-dhcp-option-43/ Share this:StumbleUponDiggRedditLike this:LikeBe the first to like this […]

  2. […] to manually configure the Certificate Authority (CA), the 1.1 release will, where available, query Option 43 and download the necessary CA certificate, a process already utilised by Lync Phone Edition […]

  3. […] in the same fashion that the existing Lync Phone Edition devices operate.  This requires that DHCP Option 43 is properly configured for the target Lync environment and the phones have access to the Lync […]

  4. […] APs (there is a lot of information out there with regards to using it for Cisco Aironet APs and Microsoft Lync 2010, but NOTHING for Brocade APs specifically). Sidenote: If I had bothered to read the Cisco link a […]

  5. […] Understanding DHCP Option 43 : Jeff Schertzs Blog. […]

  6. […] I’ve deployed a lot of Lync Phone Edition devices. Thing is, I’ve done so mainly in smaller environments where we used either a Standard Edition Front-end server or an Enterprise “pool” that consisted of a single server. Why is this important you ask? Well, let’s go to one of the best articles on DHCP Option 43: http://blog.schertz.name/2012/05/understanding-dhcp-option-43/ […]

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!