To deploy to apache (once you have a certificate) you currently need to create a custom script to export the certificate to the correct format and cpoy it to the location apache expects. The next major version (expected over the next month or two) will include a deployment task to export directly to apache (either locally or via SSH/sftp). We do not support auto configuring the certificate for apache (updating the config) so you need to do that yourself.
1 Like
Thank you a lot. But I have no idea to find the cert. How can I use Powershell to export the cert to a pfx file?
Here is some general docs for scripting:
The cert is already a pfx (p12) format file containing both you certificate and the private key. The path for the PFX file is passed into your script as a parameter. I recommen writing a script that works outside of Certify then adapt it to take the parameter for the file location:
param($result) # required to access the $result parameter
# do something with the pfx file:
$result.ManagedItem.CertificatePath
Most users who convert the pfx use OpenSSL but there are probably ways to do it using just powershell commands.
1 Like
Thanks. I’ll try it.
Hi,
I made a little script that search the latest pfx file in the directory and export the private key and the crt file to a directory you choose for apache, save it to a .ps1 file and adapt to you enviroment.
I update the code and you find it more down in this topic.
Anyway here a direct link https://community.certifytheweb.com/t/how-to-deploy-cert-to-apache-httpd/615/8?u=alescan
Hi, you should consider adapting this to use the path that gets passed in to the scripts parameter (Filezilla Server PS Script)
Your script will only work for hosting one website on the server (which is probably OK for you) but will also break in the next version when the certificate asset storage path changes (it is moving to C:\ProgramData\Certify\assets\yourdomain.com)
@webprofusion thank you for the suggestion.
Here it is the updated code.
I deleted the code in the previous post so it’s not confusing.
param($result)
$latest = $result.ManagedItem.CertificatePath
openssl pkcs12 -in $latest -passin pass: -out C:\path\to\apache\ssl.key\public.key -nocerts -nodes
openssl pkcs12 -in $latest -out C:\path\to\apache\ssl.crt\public.crt -nokeys -passin pass:
Restart-Service -Name Apache2.4 -Force
save it to a .ps1 file and adapt to you environment
P.S. You need to set the path enviroment variable for openssl in windows or run it from the openssl directory
1 Like
Hi, i am new here, i came here to ask this, we have tested the software and it looks nice, but we are also using Apache in Windows… others (Win ACME) will do it, but we prefer a GUI…
You say the next few months, this was 4 months ago. the current version we downloaded still didnt do it, however that version appears to be Match 2019, so about 10 months old. whats the real ETA for the new release?
We aim to put the correct certs (3, private, crt and chain) in the an SSL folder with the same name every time its updated so the CONF file knows the cert to use (pulls the same name, the cert is then just replaced = updated.
Please advise.
@GRIFFCOMMca yes that’s a valid criticism, I’ve spent time on other projects and commitments last year but the plan is still/again to get a beta release feb/march this year. You can achieve this using Scripting in the current release (and many people do, as per the scripts above) but the new method is/will be a little more straightforward and flexible for other service types as well.
Hi
I have looked over the above scripts, it appears though openSSL needs to be installed, we are resistive to installing support software to make software we would want to use work as it kinda of defeats the point of the software.
If this can be done (work around) with only this software and a script to move the received certs then i could likely get away with installing then removing scripts once the new one is released.
Is it possible with just a script to place the 3 files (private, cert and chain) in the correct location?
Many Thanks
OpenSSL is what is used to take the exported *.pfx and split it into the private key and public certificate(chain included). Every search to do it with pure PowerShell ends in a dead end.
I don’t think using support software defeats the purpose of Certify at all. Its main feature is to create and renew certificates for IIS(with a friendly GUI). Getting an exported file is a secondary feature. Exporting it in a format used by non-supported software is not implemented. Regardless, it is possible with a secondary feature(scripting) and works flawlessly for many people.
I think you would benefit from the next release but if you are in a hurry then please do investigate other tools or solutions. Our software generate PFX files currently, which is why they need conversion into the component parts for export to apache etc.
Is the next release going to have these files split ready for use in Apache HTTPd server?
The next version has a range of Deployment Tasks which are things you can click to add to the deployment stage of the renewal, you can then configure them as required. This includes dedicated Apache and Nginx tasks which have UI to configure your output paths etc.
Once you have a deployment task you can choose to either run it upon certificate renewal or you can defer it and run it on demand (either manually, via the command line or your own scheduled task etc) which is handy for maintenance window work etc.
Need some help… (the work i did to arrive here is at the bottom).
We have the script, which is basically the one above with a different save file path for testing, the script works when pressing TEST, however when i go get the certificate the script does not run, it only works when pressing test… any ideas?
I notice the log file says:
The term openssl is not a recognized as a the name of a cmdlet, fuciton etc…
This is interesting as it works when i press TEST, the files appear in the test folder… bug?
Next issue, the file name used in the script for the certificate, is there a way of pulling the full domain name from the $ value so i can use that in the filename or will i need to create a new script for each domain i do (so a hard coded script for each domain name in the file name for the saved cert and key).
Assuming the new software arrives, this isnt really an issue as this whole script will then be abandoned as the new software will do it instead.
How we got here… (mostly for documented purposes)
As for my findings, well Windows WILL decrypt a PFX file, but only from Windows 8.1 and above, use the Get-PfxData command in PowerShell, for this to work need PowerShell v3 or newer, Windows Management Framework 5.1 (which will load PowerShell 5.1) and then the PowerShell module PKIClient.
I got most of those to load in Windows 7 but cant get the PowerShell PKIClient to install, we spent 7 hours on it, then suddenly realized that Apache 2.4 comes with openSSL, so openSSL.exe is in the Apache BIN folder anyway… (kinda ironic).
The GUI runs under the current user while the service that does the real work runs as local system. If you’re doing something like setting a PATH variable with your OpenSSL path, it won’t be available to the service. You can just put a cd to your OpenSSL path before calling OpenSSL and that should work.
As for what you can pull from the passed variable in PowerShell, I made a list(might be old?) here: List of Script Variables
I would try $result.ManagedItem.Name for what you called the entry and $result.ManagedItem.DomainOptions.Domain for the domain name?
As certificates can contain up to 100 different domains you’d perhaps be best to name the managed certificate how you want it to appear then use that as part of the filename ($result.ManagedItem.Name)
When testing script be careful to avoid the Let’s Encrypt rate limits, specifically requesting the same cert multiple times (5 times per week). as @jljtgr mentioned the service runs your script as the Local System user so you probably want to refer to OpenSSL.exe by it’s full path.
I understand the concept of this as bumped in to this alot in the past… so if i create a cert in the GUI and it works, are you saying it may not work when the service does it? OR is the GUI using the service?
That said, if your answer was based on the problem of the script running, when i did a new domain, the script worked, so not really sure at this point what the problem was / is (or even if it is still an issue)… !
This i like, however as this should only need to run as a script for 1-3 months, i dont think i’ll tamper with the scripts, we just created a different script for each domain (there arnt many) at least then i know if that script runs the file name is correct in the SSL folder we want.
When the new software is out, then i will want to make sure the certs are being saved as the correct name.
I have noticed using the openSSL that it puts the cert and chain in the same file, which is handy as Apache needs that now…
Hi
I get that, we use the domain name for the certificate name (sub.domain.com.crt), we created a script per SSL for each domain that has the correct name hard coded as the file name.
Ive bumped in to the rate limit thing already with testing, we have the cert so it appears to work ok… I assume when i request a new one, the old one with its chain doesnt die (as we have one live and tested it too often)?