InCommon CM SSL Web Service Client

PHP Client for InCommon Certificate Manager SSL Web Service API

Notice: This an alpha-quality software at the moment. Do NOT use in production anything!!

This client provides an abstracted access layer on top of the InCommon Certificate Manager SSL SOAP Web Service.

Goals

• Create a "barrier" between client applications and the InCommon CM API so that changes do not affect clients.
• Normalize required command-formats and responses to be more user-story driven, rather than mechanical.

This package is compliant with PSR-1, PSR-2 and PSR-4. If you notice compliance oversights, please send a patch via pull request.

Install

Via Composer

{
    "require": {
        "mdwheele/incommon": "0.1.*"
    }
}

Requirements

The following versions of PHP are supported by this version.

• PHP 5.3
• PHP 5.4
• PHP 5.5

Documentation

I will have much more documentation coming soon. Until then, this is basically it.

// Create new InCommon API client.
$incommon = new InCommon();

// Submit a CSR.
try {
    $response = $incommon->certs->enroll(...args);
}
catch (InvalidUsernameException $e) {
    // Handle business.
}

...

// Check status of request.
$sslId = $response->getSSLID();

try {
    $response = $incommon->certs->getCollectStatus(...args, $sslId);
}
catch (PermissionDeniedException $e) {
    // Handle business.
}

if ($response->getStatus() == SSLCollectResponse::BEING_PROCESSED_BY_COMODO) {
    echo "Still waiting for Comodo!";
}

Todo

• Implement public Certs API 1:1 with CM Service Docs.
• Clean up public API to be more helpful.
• Clean up response / command formats.
• Implement full testing suite based on PHP-VCR so that production SOAP service is not required.

Testing

$ phpunit

Contributing

Contributions are welcome and will be fully credited.

We accept contributions via Pull Requests on Github.

Pull Requests

• PSR-2 Coding Standard - The easiest way to apply the conventions is to install PHP Code Sniffer.

• Add tests! - Your patch won't be accepted if it doesn't have tests.

• Document any change in behaviour - Make sure the README and any other relevant documentation are kept up-to-date.

• Consider our release cycle - We try to follow semver. Randomly breaking public APIs is not an option.

• Create topic branches - Don't ask us to pull from your master branch.

• One pull request per feature - If you want to do more than one thing, send multiple pull requests.

• Send coherent history - Make sure each individual commit in your pull request is meaningful. If you had to make multiple intermediate commits while developing, please squash them before submitting.

Running Tests

$ phpunit

Happy coding!

Credits

• Phil Sturgeon for documentation format. Stole!

License

The MIT License (MIT). Please see License File for more information.