I have tested the SAN certificate, it is working great with our environment.
But i am facing issue with renewal and using the script with multiple CAS servers on two sites behind same common name. Our CAS servers are load balanced on KEMP hardware LB. When I run the ACME-Exchange.ps1 script , so sometime it validate all SAN names , and sometime it failed to validate. After some troubleshooting I found that during domain validation it is hitting the other CAS on which script is not running. So I disable the other virtual server (CAS) on LB , and domains were successfully validated. So I was thinking that we cannot automate the certificate renewal in this way, because every time I have to disable the other virtual servers on KEMP.
Anyone else is using the same script for multiple CAS servers behind Load balancer with same common name ???
Our environment is that we have two sites , with same common name :
DNS records: Mail.pern.edu.pk : Site1_PulbicIP_VIP-LB
Site2_PublicIP_VIP-LB
I bet you will get more useful help if you start a new topic (about renewal with CAS and load balancing), because your situation is more specific than just âSSL cert for Exchange 2013â and not so many new people are likely to join this older thread at this point.
It is slightly different. I only have to delete the sysVault folder to have the script run correctly. As soon as it has run once with the sysVault folder in place, I get the error as described above. I do not have to run lines 98 or 99. And I think running line 100 will not help as the sysVault folder only contains two files: 00-VAULT and .acme.vault.
Another thing is that the Exchange Back End website does not bind the new certificate automatically. It sticks with the âoldâ certificate (which in this case was still valid). Is this intended, or should the script cover that?
Weâve already discussed the certificate installation and renewal when using load balancing - check the other posts. The solution was to enable just one of the nodes for the port 80 LE validation traffic on the LB and perform the certificate request and validation on it - that way the validation hits the correct node. Then install the certificate from the active validation Exchange server to all CAS servers - youâll have to modify slightly the PowerShell/EMS command but youâll figure it out.
I don't have an idea what you are doing with the script - if you want to modify it, deal with issues and share your experience.
Another thing is that the Exchange Back End website does not bind the new certificate automatically. It sticks with the 'old' certificate (which in this case was still valid).
That's not an issue - that's how Exchange works. The Let's Encrypt certificate should be and is installed on the Default (front-end) Exchange Web Site - that's what the clients are hitting when accessing the Exchange Virtual Directories.
The back-end website uses the self-signed Exchange certificate for communication with other Exchange servers in the organization, and the fact that it is a self-signed certificate is not a problem for this communication; that's how Microsoft designed this and if you want, you can replace the back-end certificate as well. Keep in mind, that if you delete the self-signed certificate in the Exchange Admin center or EMS, you will hit a very nasty problem. Everything will seem to continue working until you reboot the server or restart IIS. Then you will not be able to connect to the server with EMS or Exchange Admin Center until you assign a certificate to the Back-end web site (just a friendly warning as a lot of people hit this issue when they delete the self-signed cert as they think they don't need it).
I am just using the script as downloaded. I had noting changed.
However, if I delete in line 100 the part â -Exclude â00-VAULTâ,".acme.vault" â it goes without errors in subsequent runs. Is any harm done or are there any disadvantages in having deleted the complete sysVault folder after installation or renewal of a certificate?
As to the Exchange Back End website: sorry, my mistake. I mixed things up. The Default Web Site binds fine with the new certificate automatically.
You create a LE account at the very beginning of the script, and a key pair is generated and used to prove your identity and encrypt all communication with LE - thatâs the reason to keep the 00-VAULT. Of course, you can delete everything and create a new LE account every time you renew the LE certificate (at least LE allows this) but this doesnât make much sense.
May be you should clear everything and try again - the script works as it is and a lot of people are using it without any issues.
Netometer,
Like a couple of others, I seem to be having the same issues with renewals as some others, in that the first run is fine, but subsequent runs fail with the same errors that others have suggested above.
Iâm Server 2012R2, Exchange 2013. The only modification to your script, beyond the 3 in your videos, is at Line 55 I have inserted another line to ensure that the well known folder is browsable:
c:\windows\system32\inetsrv\appcmd.exe set config âDefault Web Site/.well-knownâ -section:system.webServer/security/access /sslFlags:âNoneâ /commit:apphost
c:\windows\system32\inetsrv\appcmd.exe set config âDefault Web Site/.well-knownâ -section:directoryBrowse /enabled:true /commit:apphost
As others have suggested, deleting sysvault allows it to rerun cleanly, but this is a bit of a dirty fix, and will limit the number of entries that are possible with the SAN, as each run makes it a new account?
Not entirely clear if the issue lays with your script, ACMESharp or my configuration, but keen to implement a cleaner fix than what Iâm going to have to do in a few weeks, which is add a line at the beginning to delete sysvault.
Thanks for the script and videos, really helpful and genuinely useful - keep up the great work!
In addition, will constantly deleting the vault lead to a flood of âyour certs are about to expireâ which LE send out when your certs are a couple of weeks from expiration, due to all the duplicate accounts Iâm creating with every run?
Weâll try to reproduce the issue. Regardless of the registration, youâll get an expiration warning for each certificate that LE issued to you (sent to the email address provided during the registration).
PS: You donât need to configure as browsable the .well-known directory.
