You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Discovered an interesting bug that can occur if a user mistakenly names a certificate with a prefix of WILDCARD.
If a user creates a certificate with the CN: wildcard.fqdn, Lemur will name it along the lines of: WILDCARD.fqdn-SymantecCorporation-<some-timestamp>. The user intended to create a wildcard certificate, but mistakenly typed in wildcard as the CN.
When the user realizes the mistake, they will create another certificate; only this time, it's a proper wildcard cert: *.fqdn. The name Lemur provides to this certificate is the same name as the previous cert: WILDCARD.fqdn-SymantecCorporation-<some-timestamp>. It's possible for the timestamp to be the same.
If the user chose to upload the certs to AWS – no errors will result. However, the old cert is what appears on ELB's. The solution was to temporarily disable the ELB listeners (if assigned), delete the cert from AWS, revoke the bad one, and manually upload the new one.
I suppose a way to prevent this from happening is to check if the user wants to name something with wildcard, and suggest the user actually create a wildcard cert. Of course, the user can and should override this in the event they actually have a service named wildcard.
The text was updated successfully, but these errors were encountered:
The * to WILDCARD name expansion is largely an artifact of AWS disallowing special characters when uploading to IAM. Then, when uploading the certificate to AWS the FQDN is based solely on the name and account of the certificate. Hence, we get into the situation above where *.example.com and WILDCARD.example.com are roughly equivalent.
Possible Solutions:
Make the certificate name globally unique (append numeric when necessary).
Warn the user that they are using a reserved domain wildcard.
Ignore this AWS specific limitation - store the * in lemur and only put wildcard in when uploaded via aws plugin.
I believe the first option is probably the best as Lemur certificate names should generally be unique anyway.
Discovered an interesting bug that can occur if a user mistakenly names a certificate with a prefix of
WILDCARD
.If a user creates a certificate with the CN:
wildcard.fqdn
, Lemur will name it along the lines of:WILDCARD.fqdn-SymantecCorporation-<some-timestamp>
. The user intended to create a wildcard certificate, but mistakenly typed inwildcard
as the CN.When the user realizes the mistake, they will create another certificate; only this time, it's a proper wildcard cert:
*.fqdn
. The name Lemur provides to this certificate is the same name as the previous cert:WILDCARD.fqdn-SymantecCorporation-<some-timestamp>
. It's possible for the timestamp to be the same.If the user chose to upload the certs to AWS – no errors will result. However, the old cert is what appears on ELB's. The solution was to temporarily disable the ELB listeners (if assigned), delete the cert from AWS, revoke the bad one, and manually upload the new one.
I suppose a way to prevent this from happening is to check if the user wants to name something with
wildcard
, and suggest the user actually create a wildcard cert. Of course, the user can and should override this in the event they actually have a service namedwildcard
.The text was updated successfully, but these errors were encountered: