SSL Plugin question

Discussion in 'Troubleshooting' started by galaxy, Aug 17, 2016.

  1. galaxy

    galaxy Mega Poster

    Messages:
    239
    When entering CSR information in the store, I was hoping to be able to validate the information going into the CSR with the "validate_csr_data" function. Specifically I'd like to assure the common_name or domainname begins with a "*." if the product is a wildcard certificate. But the function doesn't get called when you try to place the order, but instead appears to be called after the order is placed and paid for.

    Is there a way to do this validation in the plugin? Or does this need to be done in the store code?
     
  2. dkolvakh

    dkolvakh Odin Team

    Messages:
    309
    Hello.

    validate_csr_data isn't called directly and even not exists in API. Instead of it, HSPC::SSL::API->validate_cert_form will be called, ant it will call validate_csr_data method in plugin in case of manually entered data, or validate_csr in case of uploaded CSR. Method HSPC::SSL::API->validate_cert_form has been called on different stages of purchase process, not only during order provision.

    If you will guide us with detailed explanation of needed usecase with exact steps described, we can think about treating it as a feature request.
     
  3. galaxy

    galaxy Mega Poster

    Messages:
    239
    From the SDK manual (page 345):

    The validate_csr_data method is mandatory.

    So why is it in the SDK if you say it doesn't isn't called or even exists? Why tell us its mandatory?
    But there is no mention of a "validate_cert_form" in the SDK manual. Can you provide insight to what its signature is, how it should be used, and what should be returned?
    I don't see that called or used in any of the other plugins like the eNom one that I'm using as a reference.
    There is however a "validate_contact_form", but that has nothing to do with the information in the CSR.

    The problem at hand is that a "wildcard" SSL certificate needs the domain name or common name to begin with a "*.", for example *.example.com or *.subdomain.example.com.
    A non-wildcard certificate cannot begin with the "*.". Once they've entered the data and if its wrong, once they pay for the order to go through, it will just get rejected by the backend system.
    Then there's no way to fix it either other than canceling the order and re-entering everything on a new order.

    So whats required during data entry is a way to validate for the product or certificate they've selected that they enter a valid common name in the CSR.
     
  4. dkolvakh

    dkolvakh Odin Team

    Messages:
    309
    Hello.

    Please do not mix API layer and plugin middle-tier level. The validate_csr_data method is mandatory in the plugin middle-tier. The validate_cert_form method exists in API, please check p.130 of the SDK.

    While we talking about wildcard certificates, please refer to eNom SSL plugin which supports wildcard certificates issuing.
     
  5. galaxy

    galaxy Mega Poster

    Messages:
    239
    To developers, they're all API's. It doesn't appear that we have any control over that API though to implement any validation.
    Yes, eNom "supports" wildcard certificates as does the one I wrote. However, based on the SSL product (of whether the product is a wiildcard certificate or a normal certificate), no validation of the common name to assure that it matches the selected SSL product is made. That's what my point was. So if you supply a wildcard common name to a normal certifcate, or provide a regular common name to a wildcard certificate, the order will go through the store but fail later (rejected by the backend) and there's no way to fix it other than cancel, refund, re-submit with the correct common name.
     

Share This Page